Gründe für die Verwendung der lesbaren SQLite-Datenbank

Die Android-Klasse SQLiteOpenHelper verfügt über eine Methode zum Zurückgeben einer lesbaren Datenbank sowie einer schreib- und lesbaren Datenbank. Derzeit verwende ich nur beschreibbare Datenbank und habe keine Probleme, aber ich frage mich, was wäre der Vorteil zu ändern, um nur lesbar zu verwenden, wenn ich nur eine asynchrone Aufgabe (oder Aktivität) einlesen.Gründe für die Verwendung der lesbaren SQLite-Datenbank

Es könnte Leistungsvorteile geben, aber ich habe keinen Bezug zu tatsächlichen Zahlen gesehen. Wenn ich weiterhin zwischen lesbar und schreibbar wechsle, hat die Änderung einen Overhead, der den gesamten Leistungsvorteil wegnehmen könnte.

Hat jemand irgendwelche reellen Zahlen oder Erfahrung damit? Lohnt es sich, einen separaten Zugang zu implementieren?

Quelle

2010-12-29 Manfred Moser

Ich habe es allgemein als eine Schutzmaßnahme mehr als Leistung interpretiert. Man könnte alle Java-Klassen/Methoden/Datenmitglieder öffentlich deklarieren, aber wir verwenden 'protected',' private' und package-'protected', um uns davon abzuhalten, etwas zu vermasseln. In ähnlicher Weise könnte eine lesbare Datenbank dabei helfen, Codierungsfehler zu erkennen. Da SQLiteOpenHelper die Datenbank bei einem zukünftigen Aufruf von getWritableDatabase() transparent auf die Schreibberechtigung "upgradet", ist der Wert wahrscheinlich etwas begrenzt. – CommonsWare

Danke für diesen Hinweis. Ich denke, ich werde mich in diesem Stadium, wie unten erwähnt, nicht stören. –

Ich kann die Leistungsvorteile nicht kommentieren, aber ich versuche immer, nach dem Prinzip der" guten Praxis "(oder" best practice ") für jeden Zugang zu 'Daten' zu arbeiten Quellen (Textdateien, DBs oder was auch immer).

Wenn man die Dinge allgemein betrachtet (nicht Android-spezifisch), müssen die Entscheidungen, die man bei der Entscheidung über die Zugriffsebene treffen muss, auf die auszuführende Operation sowie auf äußere Einflüsse zurückgeführt werden.

Zwei Beispiele, die ich denken kann ...

Wenn ein externer Prozess haben die Verantwortung der Pflege der Daten kann - in diesem Fall kann es so ‚geöffnet‘ haben die Datenquelle dass blockiert alle außer 'lesen' Zugriff von anderen Prozess während der Wartungsphase. In diesem Fall wird Ihrem Code der Zugriff verweigert, wenn Sie Lese-/Schreibzugriff anfordern, wenn es nicht notwendig ist.
Das Risiko der Beeinträchtigung der Datenintegrität - Hacks in Systeme von der Außenwelt können über eine Sicherheitslücke mit internem Code, der Lese-/Schreibzugriff auf Daten hat, wenn wirklich nur Lesezugriff benötigt wurde, erreicht werden.

OK, können diese Punkte oder möglicherweise nicht relevant Android (vor allem, wenn die Datenquelle, um Ihre Anwendung spezifisch ist), aber, wie gesagt, ich versuche generell die Dinge zu sehen und ein ‚best practice‘ verwenden Ansatz. Wenn ich keinen Schreibzugriff benötige, bitte ich nicht darum.

Quelle

2010-12-30 00:15:31 Squonk

Während ich mit Ihren Punkten einverstanden bin, gelten sie in diesem Fall nicht für Android. Es gibt keinen db-Server als solchen, sondern eine einzigartige db-Datei und einen Zugangscode (naitve und via dalvik vm), der für diese Anwendung einzigartig ist. Innerhalb jeder App ist der Zugriff auf die Datenbank exklusiv (erzwungen) und sequenziell. Wenn eine andere App eine db hat, ist es eine separate db-Datei und exections für den Zugriff und alle (jede App hat ihre eigene vm). Wie du oben in dem anderen Kommentar gesehen hast, sagt das Javadoc sogar, dass das gleiche Objekt zurückgegeben wird, so dass alles noch weniger Sinn macht. –

@Manfred Moser: Ja, mir ist klar, dass Apps in ihrem eigenen vm existieren und ich bin ziemlich vertraut mit SQLite ohne Server (Ich benutze SQLite schon seit einiger Zeit auf verschiedenen Plattformen). Sind alle SQLite dbs 'in-process' vorhanden? Was ist mit denen, die zum Beispiel auf SD-Karte erstellt werden? Was ist mit dem Zugriff von anderen Threads innerhalb der gleichen App? Der Kommentar von CommonsWare darüber, dass wir nicht alles schaffen, "öffentlich" war im Grunde das, was ich meinte - "best practice" und all das. Nimm niemals an, dass sich deine "Arena" niemals ändern wird. – Squonk

Ich werde Ihre Antwort in diesem Stadium akzeptieren. In diesem Stadium bezweifle ich, dass ich mich bemühen werde, es umzuformatieren, da ich in meinem Fall denke, dass das ständige Schließen und Öffnen die Leistung reduzieren würde. Im Hinblick auf den Schutz sehe ich keinen Wert, da die Daten nicht kritisch sind. –

Gute Frage. Keine Nummern von mir. Die nächste Erklärung (von SQLLiteOpenHandler javadoc)

„Das (getReadableDatabase) wird das gleiche Objekt durch getWritableDatabase(), es sei denn einige Probleme, wie zum Beispiel eine Vollplatte, erfordert die Datenbank zurückgegeben werden geöffnet werden schreibgeschützt. In In diesem Fall wird ein schreibgeschütztes Datenbankobjekt zurückgegeben.Wenn das Problem behoben ist, kann ein zukünftiger Aufruf von getWritableDatabase() erfolgreich sein, in welchem Fall das schreibgeschützte Datenbankobjekt geschlossen und das Lese-/Schreibobjekt zurückgegeben wird in der Zukunft. "

Quelle

2010-12-30 00:12:42 GSree

Nice find und würde einen Weg zum Verhindern eines Fehlers auf den ersten Punkt gehen, den ich in meiner Antwort erwähne. – Squonk

@Manfred Moser Wie in meiner Antwort gesagt .... nicht sicher, ob wir dies auf die eine oder andere Weise beweisen können (d. H. Hat/hat keinen Perf Vorteil). Hier ist ein (unbestätigter) Grund, warum ich denken kann, dass dies einen Einfluss haben könnte. Wenn Sie getWorthDatenbank() verwenden, müssen Sie die close() -Methode aufrufen, ansonsten erhalten Sie in LogCat eine Menge Rot. Wobei (getTeadableDatabase() nicht den Aufruf der Methode close() anordnet. Wenn Ihre Anwendung die Datenbank häufig schließt, könnte dies (!) Die Leistung beeinträchtigen. – GSree

Gründe für die Verwendung der lesbaren SQLite-Datenbank

Antwort

Verwandte Themen