Sponsored Links |
|
||||
Gute Alternativen für die Speicherung von vielen Daten mit PHP? Ohne SQL? Gibts so weit keine sinnvollen. Es gibt verschiedene SQL Varianten...
In Text-Dateien kannst du Inhalte besser speichern, als als reinen Text (z.B. xml). Dafür gibt es dann seit PHP 5 auch viele gute PHP Funktionen. Aber PHP und MySQL gehört einfach zusammen. Die beiden arbeiten so gut zusammen, es gibt unmengen Funktionen für PHP, die die Arbeit extrem einfach machen. Und performance technisch steht dem ganzen auch nichts im Wege. Vorteile bei einem Datenbanklosem System gibt es jedoch auch. Die Installation des Systems ist einfacher. Ein einfaches Verschieben von den Dateien und fertig. Das Backup ist einfacher. Einfach die Dateien runterladen, fertig. Bei SQL müssen erst Dumps erstellt werden, die wenn du Pech hast, die Zeichenkodierung verhauen, etc. Und in seltenen Fällen hat man auch kein MySQL zur Verfügung und muss einfach auf andere Methoden zurückgreifen. Angesichts der Preise für Webhosting mit MySQL jedoch eher selten, wie ich vermute. Ein solches System ist zum Beispiel FlatPress. Ein Blog-System, an WordPress angelehnt, ohne Datenbank. Was alles in die Datenbank rein soll? Alles, was du willst. Der eigentliche Inhalt so wie so. Andere Sprachen können rein (z.B. Drupal), die Templates können rein (z.B. WBB), Dateien können rein (man kann auch binäre Daten in MySQL speichern), der Cache kann anstatt in Dateien auch in die Datenbank... Wie groß die Datenbank wird? So groß wie nötig, so klein wie möglich.. Weder übertreiben, und jedes Fitzelchen in eine Tabelle auslagern, noch in die andere Richtung übertreiben und ein CMS mit einer Tabelle erstellen. Wenn du für die Navigation zwei Tabellen brauchst, gut. Mach's so und fertig. Guck aber, dass du nicht zu viele Datenbank Anfragen machst und diese auch nicht zu kompliziert werden. Als Beispiel Drupal, weil ich bei diesem CMS im Code im Moment gut drin bin. Nur um den eigentlichen Inhalt abzuspeichern, gibt es sechs Tabellen. Allerdings bist du dann auch unglaublich flexibel und kannst wirklich alles machen. Für das "Menü" (kann man so nicht sagen, da auch das Menü so flexibel ist, dass das eigentliche Menü nur ein kleiner Teil des Funktionsumfangs ist) sind es fünf Tabellen. Der Cache nimmt sieben Tabellen, die Suche vier. Du kommst ohne Plugins schon locker auf 50. Nun kannst du dein CMS nicht mit Drupal vergleichen, welches der Inbegriff von Flexibilität ist (ähnlich wie Firefox mit den Extensions im Browserbereich). Also: Mach es wie du willst, aber übertreib nicht. Siehe in diesem Rahmen auch die Normalisierung von Datenbanken. Gruß, Pablo |
Sponsored Links |
|
||||
Um mal auf deine Letzte Frage zu antworten:
Du kannst das sicher auch alles in eine Tabelle schmeißen. Nur wirds dann unüberischtlich Mmn. Das mit den zwei tabellen geht schon inordnung. Ich empfehle dir das mit der normaliesierung. Ist vlt am anfang ein wenig trocken, aber es lohnt sich. Was auch sehr nützlich ist, sind grafische DB-Designer (MySQL-Workbench, zb.) Mit denen kannst du so eine art UML-Diagramme deiner DB erstellen in denen du alle abhängigkeiten (s. Nomaliesierung) darstellen kannst. Sehr nützlich! Achja, noch ein Tipp beim entwickeln eines CMS's. Fang nicht an einfach drauf los zu programmieren. das geht meistens schief. Am besten ist, wenn man sich vorher alles aufschreibt bzw. malt wie es am ende sein sollte. Aber ich denke das weißt du schon
__________________
Meine Spielwiese: http://blog.kanedo.net Ich bei Flickr? Da: Flickr: Fotostream von kanedo-projekt Für open Source Liebhaber: open Com Auch ich Zwitschere als @kanedo |
|
|||||||
Super, danke fuer die ausfuehrliche Antwort Pablo, aber auch an dich, gnom.
Zitat:
Zitat:
Zitat:
Zitat:
Zum einen: ein Feld in einer SQL-Tabelle mit einem solch grossen Inhalt, ist das anzuraten? (Dabei gleich die Frage: das muesste dann von Typ "Text" sein, oder?) Und vorallem: die Inhalte sind ja selbst teils mit Funktionen gefuellt und nicht nur reines HTML. Das alles dann in die Datenbank zu bringen, erschien mir irgendwie falsch, denn wenn daran was geaendert werden soll, dann soll das sowieso nicht "auf die Schnelle" passieren, also kann man dann ja auch die entsprechende Datei runterladen, aendern und neu hochladen. Und: man koennte doch auch diese Dateien fuer das CMS einfach komplett in ein textarea-Feld eines Formulares einladen und dadurch komfortabel aendern. Gibt es da trotzdem Gruende, warum der Inhalt besser in die SQL-Tabellen sollte? Denn du schreibst ja, dass gerade der dort reingehoert. Zitat:
Zitat:
Zitat:
__________________
Wenn Du mich fragst, was mir beim Erlenen von Webentwicklung am meisten Probleme bereitet, dann antworte ich: IE. |
|
||||
Performance Text vs. DB ist immer so eine sache. Merklcih gibt es mEn keine.
Aber die DB ist eiegntlich besser zu handhaben. Man kann komplexe sachen einfacher auslesen, als aus ner XML datei. Achso, à propos XML: SPL sehr nützlich!!
__________________
Meine Spielwiese: http://blog.kanedo.net Ich bei Flickr? Da: Flickr: Fotostream von kanedo-projekt Für open Source Liebhaber: open Com Auch ich Zwitschere als @kanedo |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Fonts - Lizenzen und Nutzung | heho | Grafik, Design, Typografie | 3 | 01.09.2010 23:21 |
Ernsthafte Fragen zu MySQL und seiner Indizierung | KartoffelKiffer | Serveradministration und serverseitige Scripte | 2 | 26.01.2008 01:36 |
MySQL Query - online ok, lokal kein Ergebnis? | Boris | Serveradministration und serverseitige Scripte | 6 | 05.09.2007 00:51 |
mySQL Problem | Sp33dy G0nz4l3s | Serveradministration und serverseitige Scripte | 4 | 19.08.2007 17:55 |
MySQL Service deinstallieren | NEOX | Serveradministration und serverseitige Scripte | 1 | 28.08.2006 20:55 |