SQLite Datenbanken in mobile Apps

[Dsimon24]

Moin zusammen.

Aktuell programmiere ich viel in PHP. Wie ihr an meinen vielen Fragen dazu auch sehen könnt.

Ich schaue mir gerade parallel die Entwicklung von mobilen Apps für Android und iOS an.
Dort wird im Bereich der Datenspeicherung meist von SQLite gesprochen.

Aktuell arbeite ich eher mit MySQL.

Wo genau liegt der Vorteil einer SQLite-Datenbank im Vergleich zur relationalen Datenbanken?

Wenn ich die Daten in einer App mittels SQLite speichere, kann ich dann zu MySQL synchronisieren?
Oder sollte bspw. eine WebApp programmiert in PHP auch an SQLite angebunden werden?

Oder wir habe ich das alles zu verstehen? Ich kann dazu leider nicht viel, mir hilfreiches im Internet finden.

VG

 

[BeBur]

SQLite machst du wenn du lokal auf dem Gerät speichern möchtest. MySQL nimmst du, wenn die Daten bei dir auf dem Server gespeichert werden.
Generell besteht der Vorteil von SQLite darin, dass SQLite keine Installation oder Setup benötigt. Eine SQLite Datenbank ist einfach eine einzelne Datei.

 

[Groug]

Generell besteht der Vorteil von SQLite darin, dass SQLite keine Installation oder Setup benötigt.

sqlite benötig ggf. durchaus libs, ein cli und so weiter.

 

[abcddcba]

Wo genau liegt der Vorteil einer SQLite-Datenbank im Vergleich zur relationalen Datenbanken?

SQLite ist auch eine relationale Datenbank, wie kommst du darauf dass es keine ist?

Ich kann dazu leider nicht viel, mir hilfreiches im Internet finden.

naja ...
Sowohl Wikipedia

SQLite is a relational database management system contained in a C library. In contrast to many other database management systems, SQLite is not a client–server database engine. Rather, it is embedded into the end program.

als auch die SQLite Produkt-Seite selbst

SQLite is not directly comparable to client/server SQL database engines such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is trying to solve a different problem.

Client/server SQL database engines strive to implement a shared repository of enterprise data. They emphasize scalability, concurrency, centralization, and control. SQLite strives to provide local data storage for individual applications and devices. SQLite emphasizes economy, efficiency, reliability, independence, and simplicity.

SQLite does not compete with client/server databases. SQLite competes with fopen().

beantworten dir das schon ausreichend (mMn).

 

[Dsimon24]

Wie sollte denn am besten eine SQLite-DB
mitbringt dich auf dem Server befindend
MySQL-DB synchronisiert werden?

 

[Myron]

Das kommt ganz auf die Applikation und die Daten die synchronisiert werden sollen an.

 

[GroMag]

Wie sollte denn am besten eine SQLite-DB
mitbringt dich auf dem Server befindend
MySQL-DB synchronisiert werden?

Nur über Scripte. Ein direktes Synchronisieren geht nicht. (Soweit ich den Text überhaupt entziffern kann...)

Wobei hier sowieso die Frage ist, ob es Sinn hat, 2 getrennte DBMS zu nutzen um die dann zu syncen.

 

[AW4]

Wobei hier sowieso die Frage ist, ob es Sinn hat, 2 getrennte DBMS zu nutzen um die dann zu syncen.

Die Frage ist viel mehr, ob die notwendigen, lokalen Daten so komplex sind oder so komplex werden können, dass das Speichern dieser Daten in einer SQLite-Datenbank einfacher ist, als sich ein eigenes, passendes Dateiformat samt navigationslogiken auszudenken.

Manchmal hast du einfach Daten, bei denen die Notwendigkeit nicht gegeben ist, sie durchs Internet zu schieben und dann kannst du dafür folglich auch nicht einfach einen Datenbank-Server neben deiner eigenen App laufen lassen.

 

[GroMag]

als sich ein eigenes, passendes Dateiformat samt navigationslogiken auszudenken.

Das meine ich damit, lokal in zB Json und remote mysql.

 

[AW4]

Wobei hier sowieso die Frage ist, ob es Sinn hat, 2 getrennte DBMS zu nutzen um die dann zu syncen.

Ich will noch ergänzen, dass SQLite so gesehen kein DBMS ist, zumindest kein vollständiges.
Es ist viel mehr nur die Database Engine eines DBMS und um genau zu sein eine Embedded Database Engine.
Am Ende also hochgezüchtetes File-Handling.

Das meine ich damit, lokal in zB Json und remote mysql.

Ich bin nicht up-to-date, wie perfide gut verfügbare Json-, XML- oder ähnliche Parser heutzutage mit Dateien umgehen können, nur läufst du mit textbasierten Dateilösungen irgendwann auf das Problem, dass du ab bestimmten Größen nicht jedes Mal die komplette Datei am Stück in den Speicher laden und auch nicht jedes mal die komplette Datei auf deinen Festspeicher schreiben willst.
Wenn wir von Kilobytes reden, wird das wahrscheinlich in den allermeisten Fällen kein Problem sein, aber bei mehreren MB werden dann je nach Anwendungsfall langsam aber sicher die Probleme anfangen.
Vor allem, wenn du kontinuierlich dafür Sorge tragen musst oder willst, deine Daten auf die Platte zu "sichern".

Ab hier hast du dann die Wahl, eigens dafür zu sorgen, dass deine Datei nur partiell geladen und gespeichert wird, bzw. eine Bibliothek zu suchen, die dir hierzu die Arbeit erleichtert, am Ende die Arbeit aber nicht ganz abnimmt, weil deine Anforderungen ans Dateiformat u.U. zu speziell sind oder du greifst auf sowas wie SQLite zurück, was dir die komplette Arbeit in dem Bereich abnimmt.
Allerdings mit dem Tradeoff, dass du deine Daten nun per SQL handeln musst.

SQLite ist aber natürlich auch nicht der heilige Gral, denn eine Datenbank braucht immer mehr Platz, als die reinen Daten, die sie enthält, was Anwendungsumgebungen mit rarem Speicherplatz u.U. ausschließt.

 

[GroMag]

Es ist viel mehr nur die Database Engine eines DBMS und um genau zu sein eine Embedded Database Engine.

Hast du die Links auch mal gelesen? Daraus geht nämlich auch eindeutig hervor, dass SQLite ein DBMS ist.

Wenn wir von Kilobytes reden

Tun wir, weil sonst fragt man die (Haupt)DB, sprich in diesem Fall die remote mysql, ab. Klar könnte man auch größere Datenmengen lokal zwischenspeichern. Aber dann hat man das Problem der nicht vorhanden Synchronität der "DBs".

Die Hauptfrage ist einfach: welche Daten, und vor allem wie viel, braucht man wo.

 

[AW4]

Hast du die Links auch mal gelesen? Daraus geht nämlich auch eindeutig hervor, dass SQLite ein DBMS ist.

Natürlich habe ich das, aber eindeutig fand ich das nicht.
Deswegen habe ich auch geschrieben, "dass es zumindest kein vollständiges" DBMS ist.
Die Unterscheidung dafür ist wohl aber auch nicht sehr einfach zu treffen, da der Begriff eines DBMS selbst sehr vage definiert ist.
Die Beschriebung von SQLite selbst schreibst auch, dass sie eine Database Engine sind und nimmt den Begriff DBMS erst gar nicht in den Mund.
Und das ist Absicht, denn der Anwendungsfall für SQLite ist ein deutlich anderer als der einer zentralisierten Datenbank und beschränkt sich hauptsächlich und ursächlich auf den "Ersatz" von Dateien.

Tun wir, weil sonst fragt man die (Haupt)DB, sprich in diesem Fall die remote mysql, ab. Klar könnte man auch größere Datenmengen lokal zwischenspeichern. Aber dann hat man das Problem der nicht vorhanden Synchronität der "DBs".

Die Hauptfrage ist einfach: welche Daten, und vor allem wie viel, braucht man wo.

Naja, öffne hier mal ein wenig mehr deine Vorstellung.
Es gibt Fälle bei denen du einfach nur lokale Daten hast, die deine Anwendung braucht/generiert, du aber überhaupt nicht in deiner großen, zentralen Datenbank liegen haben willst.
Evtl. willst du die nur in aggregierter Form oder nur irgend welche daraus ableitbaren Meta-Daten bzw. Ergebnisse.
U.U. gibt es auch gar keine zentrale Datenbank, weil die Anwendung rein lokal agiert oder alles verteilt gehalten wird.
Oder du kannst oder willst es dir schlicht nicht leisten oder den Groll deiner Anwender riskieren, massenweise Daten durch die Gegend zu funken. (Vor allem im mobilen Bereich.)
Vielleicht bist du auch so in der Pampa unterwegs, dass Übertragungen nur zu bestimmten Zeitpunkten möglich sind oder die Übertragung im Verhältnis zur Erzeugung der Daten so langsam ist, dass du zwingend einen Zwischenspeicher brauchst.

Alles Anwendungsfälle, die Potential haben, sich in deutlich höheren Regionen als Kilobytes zu bewegen.