Datenbank abfragen

[JoergNi]

Hallo
Ich hab eine Frage zur richtigen Datenbank Nutzung. Ich habe ein lokale sqlite DB due irgendwann einmal 500.000 Koch Rezepte beinhalten soll. Wie nutze ich die Abfragen soll ich gleich in der Start activity alles abfragen und objecte anlegen oder in den cash? Oder jedesmal wenn ich ein Rezept Aufrufe die ganze DB durchsuchen und ein Objekt anlegen?

 

[LimDul]

Eine Datenbank ist dazu da Daten zu halten und zu durchsuchen.

Sprich, es ist nicht sinnvoll alles in der Anwendung im Speicher vorzuhalten, sondern ein sinnvolles Datenbankschema zu haben, um dann die Datenbank die Suche durchführen zu lassen.

 

[nit19969]

Eine Datenbank ist dazu da Daten zu halten und zu durchsuchen.

Sprich, es ist nicht sinnvoll alles in der Anwendung im Speicher vorzuhalten, sondern ein sinnvolles Datenbankschema zu haben, um dann die Datenbank die Suche durchführen zu lassen.

Danke für die schnelle Antwort, klingt logisch. Sry für meine blöde Frage.

 

[mihe7]

Danke für die schnelle Antwort, klingt logisch. Sry für meine blöde Frage.

So blöd ist die Frage nicht, denn tatsächlich wäre es der Idealfall, alles im RAM zu halten. Leider ist RAM verhältnismäßig teuer, steht daher in wesentlich begrenztem Umfang zur Verfügung, weswegen meist auf Sekundärspeicher zurückgegriffen wird. Das ist jedoch kein Muss.

So wäre es völlig krank, bei einem DB-Server, der ausschließlich für die DB verwendet wird, nur einen Bruchteil des zur Verfügung stehenden RAMs zu nutzen.

Anderes Beispiel: die PDAs von Palm (Palm III etc.) verfügten über keinen beschreibbaren Sekundärspeicher für Daten oder installierbare Anwendungen. Vielmehr waren vom Benutzer installierte Anwendungen und Daten ausschließlich im RAM vorhanden.

Die Antwort von @LimDul berücksichtigt dagegen die normalen Umstände: viele Anwendungen und noch mehr Daten müssen auf Geräten ausgeführt werden, die mit relativ wenig RAM ausgestattet sind, dessen Inhalt darüber hinaus nach einem Reboot verloren ist. Und schon müssen Kompromisse gemacht werden, die letztlich so aussehen, wie LimDul es geschrieben hat.

 

[M.L.]

Als Kompromiss *könnte* man sich eine Kombination aus einer Aufteilung in einen "In-Memory-Bereich" (für "hot data") sowie einer klassischen Lösung (für "cold data") ansehen: https://de.wikipedia.org/wiki/In-Memory-Datenbank (sowie deren Vor- und Nachteile)

 

[Thallius]

Bei 500.000 Rezepten sollten bei einer gut designier DB eigentlich jeder Query unter 250ms dauern. Somit wäre jegliche Optimierung im Vorfeld sicher quatsch

 

[temi]

Bei 500.000 Rezepten sollten bei einer gut designier DB eigentlich jeder Query unter 250ms dauern. Somit wäre jegliche Optimierung im Vorfeld sicher quatsch

Ich denke auch, dass sich der TO da keine Sorgen machen muss. Rezeptdatenbank klingt jetzt nicht nach den allerhöchsten DB-Zugriffsraten.