Ein Freund und ich diskutierten darüber, ob er MySQL oder eine Flatfile-Datenbank für das Backend seiner Website verwenden sollte. Ich sagte ihm, er solle mit MySQL arbeiten, weil er strukturiert sei, gute Aufzeichnungen mache und konsistent sei. Auf der anderen Seite sagte er, dass er lieber auf Geschwindigkeit setzen würde. Das Lesen von Dateien ist viel schneller als die Verbindung zu MySQL und ich frage mich, ob er recht hat. Zum Beispiel, warum nicht einfach einen Ordner für jede Tabelle erstellen, so: users/ groups/ posts/ , innerhalb der Ordner haben die Dateien nach ID benannt ( 1 , 2 , 3 ) und dann Verwenden Sie für die Daten ein Format wie folgt: username: John\npassword: e2fc714c4727ee9395f324cd2e7f331f\nemail: [email protected] ?
Mit anderen Worten, was sind die Vorteile von MySQL gegenüber Flatfiles?
Mit anderen Worten, was sind die Vorteile von MySQL gegenüber Flatfiles?
MySQL bietet Indizes und Joins (für die Ausführungsperformance), Transaktionen (für die Datenintegrität) und SQL (für die Entwicklungsleistung).
Es Ihr Projekt beinhaltet nur eine 3 -line autarke Textdatei, Sie brauchen nicht MySQL .
Das Lesen von Dateien ist viel schneller als das Herstellen einer Verbindung zu MySQL, und ich fragte mich, ob er recht hatte.
Hobcobbles. Eine Datenbank wie mySQL speichert ihre Daten auch in Dateien, bietet aber viele Optimierungen, am offensichtlichsten ihre Indizierungsfähigkeiten, die im Vergleich zum Lesen (oder Schreiben) einer großen flachen Datei enorme Leistungssteigerungen ermöglichen.
Flache Dateien können in bestimmten sehr begrenzten Fällen schneller sein, aber eine Datenbank-Engine nutzt die Erfahrung von Generationen von Entwicklern, die daran arbeiten, den Datenzugriff schneller und zuverlässiger zu machen. Denken Sie nur über Race-Bedingungen und Sperren nach, wenn zwei Instanzen Ihres Skripts beispielsweise versuchen, Daten in die Datenbank zu schreiben.
Wenn die verwendete Datenmenge einige Zeilen in einer CSV-Datei überschreitet - oder in Dateien, wie z. B. den Seiten eines Wikis, nicht leicht zu verwalten ist -, gehen Sie mit einer Datenbank über. Es fügt eine Schicht der Komplikation hinzu, aber spart Ihnen eine Menge Kopfschmerzen.
Denken Sie einfach daran, eine SELECT * FROM posts WHERE MONTH(post_date) = "2010-03-10" in einer flachen Datei schnell zu machen und was nötig ist, um von Grund auf neu zu schreiben, um das zu erreichen.
Was ist bitte eine "Flatfile-Datenbank"? Eine flache Datei ist eine flache Datei - nam es so. Es ist eine Flat-File-Datenbank, die Sie glauben lässt, dass sie magisch einige Funktionen einer Datenbank hat - welche Flat-Files per Definition nicht haben.
Was sind die Vorteile von MySQL gegenüber? Flatfiles?
Überspringen Sie MySQL hier - die Hauptfrage, die Sie stellen, lautet: "Warum überhaupt eine Datenbank benutzen?".
Ich schlage vor, dass Sie die Performance überprüfen (Sewarch-Operationen - Indizes gibt es aus einem bestimmten Grund) und schlagen Sie den Begriff "ACID-Bedingungen" nach, um eine noch vage Vorstellung davon zu bekommen, was eine Datenbank tatsächlich tut.
Flache Dateien geben keine Garantie, und Jahrzehnte Entwickler haben all die Probleme, die sie immer wieder haben, bewiesen.
Es gibt auch die Frage der Sicherheit. Wenn Sie die flachen Dateien nicht ordnungsgemäß schützen, können sie viel leichter exponiert werden. Vor allem, wenn Sie Benutzerinformationen speichern, gibt es keine Barriere für die Einreise rund um die flachen Dateien.
Unter der Annahme, dass Ihre Website oder Anwendung vertikal wächst, werden flache Dateien auch nicht skaliert, denn je größer die flachen Dateien werden, desto länger dauert das Lesen.
Und schließlich ist die Verwendung von flachen Dateien, wenn es schon so einfach ist, Datenbanken zu benutzen, einfach ein Hack. Es macht nicht den "richtigen Weg", dass EVERYONE ELSE Datenbanken benutzt, also würde ich das Gegenteil behaupten: Warum flache Dateien über MySQL benutzen? Kommt jemand anderes dazu, Ihre Bewerbung zu pflegen, nachdem Sie Ihre Entscheidung, flache Dateien zu verwenden, verstanden haben oder ihr zustimmen?
Wir brauchen ein bisschen mehr Kontext.
Wenn Ihr Freund komplette Seiten liest (Gespeicherte Anzeigen "Blobs" in der DB), dann ist ja die Verwendung von MySql nicht viel hilfreich. Wenn er granulare Daten hat (einschließlich, ich weiß es nicht, Blogposts, Newsitems, Bilder mit Metadaten, Bestelldetails), dann wird ein dateibasierter Ansatz bald zu begrenzt sein, wenn die Site nicht sehr skimpy und sehr statisch ist.
Ihre vorgeschlagene Lösung hat zwei große Nachteile:
Die Verwendung von Ordnern / Dateinamen ist dasselbe wie nur ein Index für jede Tabelle (in diesem Fall der Dateiname), so dass die Suche nach anderen Kriterien ewig dauert. Ganz zu schweigen von der Tatsache, dass viele Dateien in einem einzigen Verzeichnis das Betriebssystem zu besteuern beginnen.
Darüber hinaus ist security-by-filename ein gewisses Sicherheitsrisiko, selbst wenn Sie das Hash-Pwd als Teil der URL verwenden.
Ich habe in der Vergangenheit einige dateibasierte Anwendungen mittlerer Größe ausgeführt (aufgrund fehlgeleiteter Anforderungen konnten wir keine Datenbank verwenden), und das macht Spaß, ist aber sehr einschränkend, sobald Sie über einige hundert Dateien gehen. Und selbst mit kleinen Zahlen müssen Sie von Anfang an Tricks machen, um das Ding zum Laufen zu bringen.
Wie erhalten Sie, ohne alle Benutzerinformationen im Posts/ -Ordner zu speichern, alle von John Doe geschriebenen Beiträge (zum Beispiel)? In SQL ist es nur eine Join-Anweisung. Bei flachen Dateien müssen Sie entweder die Informationen in der eigentlichen Post-Datei speichern oder den Code schreiben, um die Join & Amp; Suchoperationen selbst.
Nur ein Beispiel: Denken Sie daran, dass Sie 1.000.000 Kunden haben, mit Adressinformationen, und Sie müssen nach Kunden suchen, die in NY leben. Wenn Sie jeden Kunden in einer separaten Datei gespeichert haben, müssten Sie alle 1.000.000 Dateien lesen und sehen, ob ein Kunde zu diesem Staat gehört. Wenn Sie alle Datensätze in einer großen Datei gespeichert haben, müssen Sie die gesamte Datei lesen und iterieren, um alle Kunden aus NY zu finden.
In beiden Fällen verlieren Sie.
Im Fall von RDBMS wie MySql - würden Sie so genannte "set" -Operation oder SELECT-Anweisung verwenden, mit Hinzufügen von Indizes würde die Engine wahrscheinlich nur 10/20% mehr Daten lesen als benötigt, um alle Kunden aus NY zu finden.
Hoffe das hilft
Datenredundanz und ein Mangel an Atomizität sind große Probleme in flachen Datei-Datenbanken, die sich exponentiell manifestieren, je mehr Daten benötigt werden und Latenz in Abfragen und andere Probleme wie Update / Delete / Insertion Anomalien einführen.
Das relationale Datenmodell mit Normalisierung hilft, diese Probleme zu negieren, indem Atomizität sichergestellt wird und jeder Datensatz eindeutig identifizierbar ist (Erste Normalform), dass jedes Feld in einer Tabelle funktional vom Primärschlüssel (Second Normal Form) und Diese Nicht-Schlüsselfelder teilen keine transitiven Abhängigkeiten von anderen Feldern in der Tabelle (Third Normal Form).
Das relationale Datenmodell ist bei weitem nicht die einzige Möglichkeit, es zu tun, vielleicht nicht einmal das beste, aber es versucht sicherlich, die Probleme der Abfragelatenz und Anomalien in flachen Dateien zu lösen.
Mysql hat einen Vorteil gegenüber Flatfile, Dateistruktur ist schlecht für die Abfrage, aber CRUD in der Datei ist schneller als MySQL, Sie können No-SQL-Datenbanken wie Mongo Db verwenden, um eine bessere Struktur und mehr Geschwindigkeit zu haben, Es gibt einige Unterschiede zwischen sql und no-sql Datenbanken, aber ich denke, es ist besser, no-sql db anstelle von flatfile zu verwenden, auch bewusst, wenn Sie Bigdata arbeiten no-sql db ist besser als sql sicher ..