W jaki sposób kursor SQLite działa wewnętrznie?

Question

Pracuję nad projektem, który wymaga przechowywania bitmap na stole. Te bitmapy są używane w adapterach danych do wyświetlania na listach. Ta tabela może zawierać więcej niż 1000 obrazów. Powodem, dla którego obecnie nie przechowuję plików, jest to, jak szybko mogę czytać i zapisywać obrazy w db.

Czego właściwie szukam, to zrozumieć ograniczenia kursora SQLite. Jak kursor jest załadowany do pamięci? Czy umieszcza wyniki zapytania w pamięci, czy tworzy jakiś typ pliku do odczytu/zapisu? Nie chcę napotkać problemów, w których zapytanie o duże zbiory danych powoduje, że w urządzeniu skończy się pamięć.

Answer 1

To jest stary post, który zrobiłem. Moim rozwiązaniem było zapisanie obrazów do pliku i zapisanie ścieżki do obrazu w tabeli bazy danych. To było czystsze i wydawało się znacznie szybsze.

Pomysł zapisywania dużych danych binarnych w tabeli nie wydaje się prawidłowy. Nie mam szczegółowych informacji, dlaczego nie jest to dobry pomysł, ale tak właśnie czuję się po badaniach.

Answer 2

Jeśli sobie przypomnę, zachowa on jednak wiele wyników w pamięci podręcznej. Powinien on zazwyczaj znajdować się poniżej soft heap limit. Jest to limit doradczy, więc woli przekroczyć limit niż zwracać SQL_NOMEM.

Nie wierzę, że zapisuje na dysk dla jakichkolwiek mechanizmów buforowania. Dopóki każdy obraz mieści się w pamięci i nie znajduje się w indeksach, nie powinien stanowić problemu.

Nie jestem programistą dla Androida, bo to jest warte. Niektóre z tych rzeczy można było dostosować.

Jako tło, sqlite_step jest kursorem w domyślnej bibliotece. Nie wiem, czy Android wdrożył własne mechanizmy. Możesz znaleźć ogólne informacje na ich stronie o dynamic memory allocation.