Eine kleine (.txt) Datenbank selber entwerfen oder sql lernen?
Was wäre effizienter?
Wenn man kein sql kann.
3 Antworten
Das hängt vom Anwendungsfall ab.
Eine Textdatei (oder auch Binärdatei) ist viel "leichtgewichtiger" und daher auch im Zugriff (wesentlich) schneller. Bei einer SQL-Datenbank läuft ein SQL-Server in einem separaten Prozess. Deine Anwendung muss SQL-Statements "zusammensetzen", diese müssen per Interprozesskommunikation an den SQL-Server übertragen werden, der diese auswerten, ausführen und die Ergebnisse zurückliefern muss. Das dauert eine ganze Weile. Direkt auf einem File-Deskriptor lesen geht natürlich viel schneller. Auch eine CSV parsen geht recht schnell und wenn die Datenmenge klein ist, kann man das Ergebnis ggf. sogar im Hauptspeicher (RAM) vorhalten, wo der wahlfreie Zugriff dann richtig schnell ist. (Die CSV-Datei selbst wirst Du sequentiell lesen müssen, weil Du im Vorfeld nicht weißt, wie lang die einzelnen Einträge sind.)
Eine Datenbank zu verwenden ist vor allem dann sinnvoll, wenn viele (Anwendungen) auf den selben Datenbestand zugreifen müssen und die Zugriffe synchronisiert und konsistent gehalten werden müssen. Solche Anwendungen findet man meist im Server- / Cloud-Umfeld.
In einem Textfile kann man keine Datenbank machen. Eine Datenbank hat gewisse Eigenschaften (siehe Kapitel Funktionen)
Du willst wahrscheinlich nur Daten sammeln.
Je nachdem was du in welchem Umfang sammeln willst können einzelne Textfiles dafür ausreichen. Das kann man aber nicht allgemein beantworten
Es kommt darauf an was in die Datei soll und ob die Daten auch gefiltert und verknüpft werden sollen
Für wenige einfache Daten reicht z.b. csv Datei die man lesen und schreiben kann.
Für alles Andere besser SQL
Vor allen wenn es Datenschutz Rechliche Dinge wären ist csv natürlich ungeeignet und fahrlässig
Das würde ich so pauschal nicht sagen. Ich würde das Filtern / Verknüpfen von Daten im Regelfall viel eher in der Anwendungssoftware selbst implementieren, als dafür eine Datenbankengine zu bemühen.
Wenn die Datenbank richtig viele Daten hat erst auslesen und dann filtern wäre unnötige Zeitverschwendung.
Genau dafür gibt es SQL um effektiv auf Daten zuzugreifen
Naja, die Datenbankengine liest ja auch aus und filtert. Das kann ich auch in der Anwendung machen. Wenn ich spezialisierten Code für mein Problem schreiben kann, dann dürfte ich diesen in der Regel performanter hinbekommen, als eine "generisch angelegte" Datenbankengine das jemals sein kann.
Wenn man jetzt nicht gerade mit vielen "Usern" auf die Daten zugreifen und die Konsistenzbedingungen erhalten möchte, sondern lediglich von einer Anwendung aus auf den Datenbestand zugreift, dann ist eine Datenbankengine letztlich Overhead, auf den man verzichten kann. Für eine Datenbankabfrage muss ich in meiner Anwendung erstmal ein Statement zusammensetzen, muss dieses (in der Regel per Interprozesskommunikation) an die Datenbank schicken. Diese muss es empfangen, muss es wieder "auseinanderenehmen" (interpretieren), dann die entsprechenden Auswertungen machen und das Ergebnis anschließend auf einem ähnlichen Wege (Serialisierung, Interprozesskommunikation, Deserialisierung) wieder an zurück an meine Anwendung kommunizieren. Bis das passiert ist, hätte ich die Auswertung in meiner Anwendung in aller Regel längst gemacht, wenngleich das möglicherweise mehr Implementierungsaufwand bedeutet.
Eine Datenbank eignet sich eigentlich insbesondere dann, wenn viele auf den Datenbestand zugreifen und dabei Konsistenzbedingungen eingehalten werden müssen - oder eben wenn der Datenbestand dermaßen groß ist, dass ich ihn verteilt speichern muss, weil er nicht auf eine Festplatte (oder ein Festplattenarray) passt.
Ist sql verschlüsselt?