Hallo Dark Sider,
ich bin mir nicht sicher, ob ich das richtig verstanden habe.

Eine Referenztabelle sollte es aber dann schon sein.

Das brauche ich aber doch eigentlich nur bei n:m-Verknuepfungen? Die habe ich ja aber hier nicht: jede Stadt gehoert zu genau einem Bundesland, während jedes Bundesland beliebig viele (0-n) Staedte hat, also 1:m. Oder?
Ich habe keine solchen Scherze geplant wie

• Baden-Wuerttemberg/Wuerzburg (liegt zwar sehr nah an der Grenze)
• Bayern/Wuerzburg (gehoert aber zu Bayern)
  auch wenn das benutzerfreundlicher waere.

Vorteil: sehr leicht zu pflegen, zu erweitern und zu ändern; sollte man feststellen, das Bayern ab morgen wieder offiziell Königreich Bayern heißt, muss man das nur an einer Stelle ändern, nicht bei jeder (königlich) bayrischen Stadt, die als Eintrag in der DB hinterlegt ist.

Aber wie unterscheidet sich das von der Realisierung ohne Referenztabelle? In der Tabelle "Regionen" gibt es nur einen Eintrag "Bayern", der mit entsprechenden Staedten in derselben Tabelle verknuepft ist. Langt doch eine Aenderung, oder?

Viele Gruesse, Eddie

Hallo Ludger,

es gibt also in diesem Beispiel anscheinend die Entitaeten "Ort", "Land" und "Kontinent". Sollte relativ klar sein, dass keine neue Entitaeten hinzukommen bzw. aus dem System entfernt werden, dann kommt man traditionell mit drei Tabellen und den 1:n-Beziehungen "Kontinent-Land" und "Land-Ort".

Entweder du machst mehrere tabellen mit jeweiligen fremdsschlüsseln oder du verwendest eine Baumstruktur.

Was spricht denn dagegen, nur eine Entitaet ("Herkunft") zu haben, mit Kontinent, Land, Stadt? Grosse Unterschiede gibts da eigentlich nicht, sind alles Ortsangaben. Per 1:n habe ich dann meine Baumstruktur. Kontinente und Laender sind fix, Staedte koennen neu dazu kommen und werden einem Land zugeteilt.
Ist es schlecht, das so zu machen?

Eddie

Hallo schildi,

"Bitte sage mir warum es eine DB sein muß!"

nuja...

-> redundanz zum beispiel

Da gebe ich Dir völlig recht! Der Römer sprach dies aus, wenn er Überfluß meinte. Ja - Datenbanken sind für simples Servieren überflüssig ;)

-> gleichzeitige datenzugriffe!

Letzlich hatte ich Toms Server mal unter Beschuß genommen und eine Dokument über 300/sec auslesen lassen. Mit anderen Worten, es kann ruhig nacheinander geschehen. Ich sehe nur nicht den Unterschied, zu einer normalen Festplatte. Einen Datenträger braucht ein Server zum servieren - damit das geornet abgeht, auch noch ein Dateisystem. Soweit komme ich mit. Bitte wofür brauche ich jetzt eine Datenbank, die ich zusätzlich in diesen Datenbezugsweg dazwischen zwenge, die Recoursen frißt und nicht grade leicht zu bedienen ist.

Außerdem muß ich nachfragen, ob eine Datei immer nur einmal gelesen werden kann?

Gruß aus Berlin!
eddi

Hallo Axel,

Was denn nun enlisch oder deutsch?

Auch eine Art eine Kommunikation zu beginnen...

Das Thema DB hatten wir doch schon ;) Bitte sage mir warum es eine DB sein muß!

1. Mehrsprachigkeit

Und es ist nicht möglich in einfachen Textdateien einen deutschen und einen Englischen teil einzustellen? Man lern hier doch nie aus. Gut wenn das nicht geht nehme ich doch gleich zwei oder sogar mehrere Dateien (inc.de / inc.en / inc.es / inc.fr / inc.nl / ...), hole mir bsw. den Accept-language und werde genauso glücklich.

2. Vermeidung von Datenredundanzen (Das "Wandern" oder den "Wintersport", in meinem Beispiel im obigen Link, kann ich jedem Bundesland, egal in welchem Staat, zuordnen.

Ich kann jedem Kontinent, jedem Land, jeder Stadt sogar ein eigenes verzeichnis zuweisen wo alle Daten abgelegt sind und nach simpelstem Schema F für label handling routine PHP zugängig machen kann.

Das geht natürlich nicht mit einer Textdatei, wo ich nicht die Möglichkeit habe mir bereich zu definieren, die standardmäßige segmentiert sind:

Sandardthema 1

text text text text text text text text
     text text text text text text text text
     text text text text text text text text

Sandardthema 2

text text text text text text text text
     text text text text text text text text
     text text text text text text text text
     text text text text text text text text

Sandardthema 4

text text text text text text text text
     text text text text text text text text
     text text text text text text text text
     text text text text text text text text
     text text text text text text text text
     text text text text text text text text

Zusatz

text text text text text text text text
     text text text text text text text text
     text text text text text text text text

3. Portierbarkeit (Deine Version "hardcodiert" die Pfadzugriffe in _einer_ Programmiersprache. Die DB codiert die Zusammenhänge in ihrerm strukturellen Aufbau, in welchem mit SQL abgefragt wird. Das ist leichter umzustellen (Daten von DB zu anderer DB, umstellen der Scripte, die per SQL abfragen, von Sprache zu anderer Sprache, wobei fast immer "Standardscripte" verwendet werden) als das Umstellen Deiner Scripte von PHP nach JSP (z.B.), was häufig Änderungen bis hinunter in die Programmablauflogik nach sich zieht.

Die gesamte Ornerstruktur ist mit einem einfachen Zipprogramm portierbar bis zum geht nicht mehr. Und es ist lediglich von PHP nicht von unterschiedlichen DB-Sprachen abhängig.

Alles, was man also braucht, wäre apache und PHP. Das gibts nun bei Hostern in fast allen Variationen zu unterschiedlichsten Preisen; bis hin zum Mietserver.

Ich weiß nicht, ob sich bei diesem Projekt überhaupt schon ein CMS lohn, grade weil Eddie das Web selbst aufgebaut hat. Wenn ich von PHP dabei rede, dann von nicht wesentlich mehr als einer Hand voll von Dateien.

Ehrlich gesagt finde ich dieses Beispiel "PHP nach JSP" für ein privates Projekt (ich gehe hofentlich da recht in der Annahme) an den Haaren herbeigezogen.

4. Alle anderen Vorteile, die Du angegeben hast, sind mit einer DB auch realisierbar, einschließlich der sprechenden Pfadangaben.

Also schalte ich noch einen apache-Handler hinzu, nur um auf Biegen und Brechen das gleiche zu erzeugen? Das kann nicht Dein Ernst sein.

5. Der angebliche Nachteil bei der Suche nach Textteilen ist bei einem durchdachten Datenbankdesign nicht vorhanden. Mit einem kleinen Suchscript wird die DB sogar _leichter_ zu pflegen sein, als Dateien in einer Verzeichnisstruktur.

Das weiß ich nicht, war auch nicht mein erklärtes Ziel dort nun Suchroutienen von PHP in einer Verzeichnisstruktur neben einer DB gegenüberzustellen.

Eine Datenbank arbeitet doch auch nur mit Dateien. Die Software meiner DB ist in meinem Beispiel einfach PHP und das Dateisystem. Bitte wo sind jetzt die tiefgründigen Vorteile einer anderen Datenbank?

Gruß aus Berlin!
eddi

Hallo Eddie,

vorneweg: Gegen Einen Kundenwunsch (sei er auch noch so
          bescheiert) hat man Leider keine Chance. Ob
          der Kunde dabei nun der eigene Prof. ist, oder
          es sich um einen reellen Kunden handelt.

Im weiteren werden Dir diese Ausführungen
          parktisch direkt von keinem Nutzen sein. Aber
          möglicherweise hast Du ein andermal Gelegen-
          heit mein Dargeletes zu prüfen. :)

res1 res2 res3 res4 res5 res6 res7 res8

verzeichnis1   +    +         +    +              +     europa_12458/
verzeichnis2        +                                   europa_12458/norwegen_2/
verzeichnis3                                            europa_12458/norwegen_2/oslo_
verzeichnis4   +    +                             +     europa_12458/niederlande_128/
verzeichnis5        +                                   europa_12458/niederlande_128/amsterdam_2
verzeichnis6   +                                        europa_12458/niederlande_128/delft_1
verzeichnis7                  +    +                    europa_12458/niederlande_128/edam_45
...

Ich hatte Dir kurz eine keine Funktion verz() zusammengezimmert, die nur nach (is_dir($v.$f) && $f!="." && $f!="..") abfragt. Dann übergebe der Funktion doch mal einen weiteren Parameter und erfrage nach explode('-',$f); in $array[1] einen/mehreren bestimmten Wert/-en ab.
Poteziell eignet sich diese Methode um pro Byte über 60 Kategorien zu erzeugen. Das sollte ausreichen.

Nun kommen wir an einem Punkt, wo man tatsächlich ein CMS-ähnliches System etablieren müßte, um diese Strukturiernung wardbar zu halten. Oderaber man liest von jeder beischreibung wie in <./?t=87724&m=522346> einen $header aus.

http://www.umdiewelt.de/Motorradreisen/Enduro (das ist noch im zweiten Baum!),

Praktischer Ansatz der /verzeichnis_{wert}{wert}{wert} -Methode ist für mich, ich bleibe in EINEM Baum. Man muß nicht erst Pseudostrukturen innerhalb einer DB einrichten, um einen Datenfeld (Inhalt von Wurzelverzeichnis) neu zu erschließen, sondern man nutz die Logischen strukturen aus.

Die Baeume ueberlagern sich also. Stell Dir mal vor, ich nehme in einem Jahr die Rubrik "Kanutouren" dazu:

• bei einer DB-Realisierung fuege ich einfach nur eine neue Zeile in die Fortbewegungsmittel-Tabelle.
• bei einer Dateisystem-Realisierung muss ich entweder die Datei erweitern oder neue Verzeichnisse anlegen. Aufwand bei b): |Regionen| * |Fortbewegungsmittel| * |Urlaubsart| ..., bei a) natuerlich geringer.

Das sei mir das allererste Argument für eine DB!

Um auch das kurz darzulegen: Ich bin um jede Kontroverse dankbar und auch der Ansicht, Fundamentalismus ist in keinem geistigem Gebiet gut. Nur ich würde endlich gerne den Mehrwert von einer DB kennenlernen wollen, um auf meinem Server die Datenbank wieder anzuschmeißen. Jedes System wird mit der wachsenden Komplexität im Innern störanfälliger.

Gruß aus Berlin!
eddi