Powody korzystania czytelny bazy danych SQLite

Android klasy SQLiteOpenHelper ma metodę powrotu czytelną bazę danych, jak również do odczytu i do zapisu danych. Obecnie używam tylko zapisywalnej bazy danych i nie mam żadnych problemów, ale zastanawiam się, jaką korzyścią byłoby zmienić używanie czytelnej tylko wtedy, gdy czytam tylko w asynchronicznym zadaniu (lub aktywności).Powody korzystania czytelny bazy danych SQLite

Nie może być korzyści wydajności, ale nie widziałem żadnego odniesienia do rzeczywistych liczb. Również jeśli przełączam się między odczytem i zapisywaniem, zmiana ma narzut, który może odjąć całą przewagę wydajności.

Czy ktoś ma jakieś prawdziwe liczby lub doświadczenia z tym związane? Czy warto wdrożyć oddzielny dostęp?

Źródło

2010-12-29 Manfred Moser

Generalnie interpretowałem to jako środek ochrony bardziej niż działanie. Można zadeklarować wszystkie klasy Javy/metody/dane publiczne, ale używamy 'protected',' private' i package -'protected', aby nie dopuścić się do zepsucia. Podobnie czytelna baza danych może pomóc w wychwytywaniu błędów kodowania. Biorąc to pod uwagę, ponieważ 'SQLiteOpenHelper' przeźroczyście" aktualizuje "bazę danych do zapisu w przyszłym wywołaniu' getWritableDatabase() ', wartość ta jest prawdopodobnie nieco ograniczona. – CommonsWare

Dzięki za podpowiedź. Myślę, że nie będę zawracał sobie głowy na tym etapie, o czym wspomniano poniżej. –

Nie mogę wypowiedzieć się na temat korzyści z wydajności, ale zawsze staram się pracować na zasadzie" dobrej praktyki "(lub nawet" najlepszej praktyki ") w celu uzyskania dostępu do dowolnych" danych " źródła (pliki tekstowe, bazy danych lub inne).

Patrząc na rzeczy ogólnie (nie Android specyficzne), decyzje mają być wykonane przy podejmowaniu decyzji o poziomie dostępu, sprowadzają się do pracy do wykonania, jak również wszelkie wpływy zewnętrzne.

Dwa przykłady mogę myśleć ...

Jeśli proces zewnętrzny może mieć odpowiedzialny za utrzymywanie danych - w tym przypadku może być „otwarty” źródło danych w taki sposób, to blokuje dostęp do "tylko odczytu" przez wszystkie inne procesy podczas fazy konserwacji. W takim przypadku Twój kod zostanie odmówiony pod warunkiem, że nie zażądasz dostępu do odczytu/zapisu, gdy nie jest konieczne.
Ryzyko utraty integralności danych - hacki do systemów ze światem zewnętrznym można osiągnąć poprzez otwór za pomocą kodu bezpieczeństwa wewnętrznego, który odczytu/zapisu dostępu do danych, jeśli tylko naprawdę potrzebne, aby „czytać” dostęp.

OK, te punkty mogą, ale nie muszą mieć związku z Androidem (szczególnie jeśli źródło danych jest specyficzne dla Twojej aplikacji), ale, jak powiedziałem, staram się patrzeć na rzeczy w sposób ogólny i używać "najlepszej praktyki" podejście. Jeśli nie potrzebuję dostępu do zapisu, nie wymagam tego.

Źródło

2010-12-30 00:15:31 Squonk

Chociaż zgadzam się z twoimi punktami, to w tym przypadku nie mają zastosowania do Androida. Nie ma serwera db jako takiego, ale raczej unikalny plik db i kod dostępu (naitve i via dalvik vm), który jest unikalny dla tej aplikacji. W ramach każdej aplikacji dostęp do db jest wyłączny (wymuszany) i sekwencyjny. Jeśli inna aplikacja ma bazę danych, jest to oddzielny plik db i przykłady dostępu i wszystkich (każda aplikacja ma swój własny plik vm). Jak zauważyłeś powyżej w innym komentarzu, javadoc mówi nawet, że ten sam obiekt jest zwracany, więc wszystko ma jeszcze mniej sensu. –

@Manfred Moser: Tak, zdaję sobie sprawę, że aplikacje istnieją w ich własnym vm i jestem całkiem obeznany z SQLite bez serwera (od jakiegoś czasu używam SQLite na różnych platformach). Czy jednak wszystkie dunes SQLite są "w trakcie procesu"? A co z tymi, które mogą być tworzone na przykład na karcie SD? A co z dostępem z innych wątków w tej samej aplikacji? Komentarz z CommonsWare o tym, że nie tworzymy wszystkiego jako "publicznego", był właściwie tym, o co mi chodziło - "najlepsza praktyka" i tak dalej. Nigdy nie zakładaj, że twoja "arena" nigdy się nie zmieni. – Squonk

Na tym etapie przyjmuję twoją odpowiedź. Na tym etapie wątpię, czy postaram się go zreorganizować, ponieważ w moim przypadku ciągłe zamykanie i otwieranie będzie ograniczać wydajność. Pod względem ochrony nie widzę żadnej wartości, ponieważ dane nie są krytyczne. –

Dobre pytanie. Żadnych numerów ode mnie. Najbliższy wyjaśnienie (od SQLLiteOpenHandler javadoc)

„To (getReadableDatabase) będzie taki sam obiekt zwrócony przez getWritableDatabase() chyba jakiś problem, na przykład pełnego dysku, wymaga, aby być otwarte tylko do odczytu bazy danych. W W takim przypadku zostanie zwrócony obiekt bazy danych tylko do odczytu.Jeśli problem zostanie rozwiązany, przyszłe wywołanie metody getWritableDatabase() może się powieść, w takim przypadku obiekt bazy danych tylko do odczytu zostanie zamknięty, a obiekt do odczytu/zapisu zostanie zwrócony w przyszłości. "

Źródło

2010-12-30 00:12:42 GSree

Ładne znalezisko i zrobiłby jakiś sposób, aby zapobiec awarii pierwszego punktu, o którym wspomniałem w mojej odpowiedzi. – Squonk

@Manfred Moser Jak powiedziano w mojej odpowiedzi .... nie jestem pewien, czy możemy to udowodnić w ten czy inny sposób (tj. Ma/nie ma przewagi). Oto jeden (niezweryfikowany) powód, dla którego mogę sądzić, że może to mieć doskonały wpływ. Jeśli używasz getWritableDatabase(), musisz wywołać metodę close(), bo w LogCat dostaniesz dużo czerwieni. Gdzie (ta część jest niezweryfikowana) metoda getReadableDatabase() nie wymaga wywołania metody close(). Jeśli twoja aplikacja często zamyka bazę danych, może to (!) Wpłynąć na wydajność. – GSree

Powody korzystania czytelny bazy danych SQLite

Odpowiedz

Powiązane problemy