Mehrfachen, gleichzeitigen Dateizugriff nicht zulassen

[Joey]

Hallo

Ich habe Textdateien, in denen Daten per PHP gespeichert werden. Nun sind die Daten in einigen dieser Dateien etwas durcheinander geraten (sind vermischt, stehen in anderen Zeilen als vorher, ...). Ich kann mir das nur dadurch erklären, dass zwei oder mehr Besucher zur gleichen Zeit die entsprechenden PHP-Scripts aufgerufen haben. Dadurch wurden anscheinend die ausgelesenen und veränderten Inhalte zur gleichen Zeit wieder in die Datei geschrieben, sodass ein Durcheinander entstanden ist.

Wenn ihr meine Vermutung bestätigen könnt: Wie kann ich verhindern, dass mehrere Besucher gleichzeitig auf eine Datei zugreifen? Der Anfang und das Ende des Dateizugriffs werden ja durch fopen und fclose definiert.

Danke euch!

[Tom]

Hello,

da muss man unterscheiden:

1. Wenn das System anfängt zu arbeiten, ist die Datei bereits
   (als leere Datei) vorhanden
2. Es ist nicht definiert, ob eine Datei zum Zeitpunkt des
   Benutzungswunsches schon vorhanden ist.

Fall 1.

Öffnen der Dateie mit

$fh  = fopen("datei","r+");
$lck = flock($fh, LOCK_EX);

Die Lockfunktion hält das Script nun solange an, bis das Dateilock

erfolgreich ist, oder Timeout des Scripters erreicht ist.

datei vollständig einlesen

$stream = fread($fh,filesize($fh));

Array mit den datensätzen wiederherstellen

$_data = unserialize($stream);

Daten verändern

Dateizeiger wieder auf Anfang

fseek($fh, 0 ,SEEK_SET);

Array wieder in Stream umwandeln

$stream = serialize($_data);

Daten wegschreiben

$ok = fwrite($fh,$data);

Datei nch den gültigen Daten abschneiden

ftruncate($fh, strlen($data));

Datei wieder schießen und freigeben

fclose($fh);

Im Fall 2 muss man die Datei "nichtzerstörend" öffnen im Modus a+, sie dann sperren, den Dateizeiger auf den Dateianfang setzen, und so weiter wie im fall 1.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Joey]

Danke, Tom, für deine Antwort!

Du hast leider einige Befehle verwendet, die ich nicht kenne.

Vielleicht zeige ich dir mal an einem Beispiel, wie ich fast immer den Inhalt einer bestimmten Zeile einer Datei verändere. Eine Zeile steht dabei z.B. für einen Gästebucheintrag.

foreach (file($textdatei) as $zeile) {
list($schluessel, $var1, $var2) = explode($trenner, trim($zeile));
 if ($schluessel==$aufgerufener_schluessel) { // Zeile in der Datei suchen
 $var1 = $var1_neu; // Werte verändern
 $line = $schluessel.$trenner.$var1.$trenner.$var2;
 $array[] = $line; // veränderte Zeile im Array speichern
 }
 else {
 $array[] = trim($zeile); // Zeile unverändert im Array speichern
 }
}
$datei = fopen($textdatei, "w+");
foreach ($array as $i) { fputs($datei, "$i\n"); } // alle Zeilen wieder speichern
fclose($datei);

Vielleicht kannst du mir hier die entsprechenden Befehle zum Datei-Sperren einbauen.

Danke für deine Hilfe.

[Tom]

Hello,

Du hast leider einige Befehle verwendet, die ich nicht kenne.

Das kannst Du ändern, indem Du unter php.net die Beschreibungen zu den Funktionen durchliest. Das geht natürlich nicht ohne Mühe.

Einen dicken Fehler hast Du auf jeden Fall beim Umgang mit dfen Zeilenendezeichen.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Eternius]

Hallo,

Datenbank.

rentiert sich auf lange zeit sowieso.

gruss

[MichaelB]

Hallo,

Datenbank.
rentiert sich auf lange zeit sowieso.

Kommt darauf an. Die klassiches relationalen Datenbanken haben ein großes Manko. Sie können nur Tabellen speichern. Das ist oftmals nicht ausreichend wenn man beispielsweise hierachische Daten hat bzw. verkompliziert das Datenmodell (was den Zugriff erschwert und vorallem langsamer macht).
Datenbanken sind kein Allheilmittel.

Ich sehe nur zwei Gründe für den Einsatz von Datenbanken.
1. Man hat Daten die sich prima als Tabelle abspeichern lassen
2. Man ist auf den Provider angewiesen der nur mySQL oder ähnliche
   Datenbanken zur Verfügung stellt

Gruß
  MichaelB

[Klaus Mock]

Hallo,

Die klassiches relationalen Datenbanken haben ein großes Manko. Sie können nur Tabellen speichern. Das ist oftmals nicht ausreichend wenn man beispielsweise hierachische Daten hat bzw. verkompliziert das Datenmodell (was den Zugriff erschwert und vorallem langsamer macht).

Datenbanksysteme müssen aber nicht zwangsläufig relational sein. Vergleiche dazu z.B. diverse Dateisysteme, Notes oder LDAP.
Wenn man den Begriff 'Datenbank' weit genug sieht, dann sind auch die Textdateien aus dem Ausgangsposting Datenbanken, allerdings mit einem schwachen, da fehleranfälligen, Verwaltungssystem dahinter.

Ich sehe nur zwei Gründe für den Einsatz von Datenbanken.

Ich dagegen sehe nur einen Grund für den Einsatz von Datenbanken. Nämlich wenn man Daten mehr oder weniger Strukturiert ablegen muss/will;-)

Grüße
  Klaus

[MichaelB]

Hallo,

Die klassiches relationalen Datenbanken haben ein großes Manko. Sie können nur Tabellen speichern. Das ist oftmals nicht ausreichend wenn man beispielsweise hierachische Daten hat bzw. verkompliziert das Datenmodell (was den Zugriff erschwert und vorallem langsamer macht).
Datenbanksysteme müssen aber nicht zwangsläufig relational sein.

Ich bezog mich ausdrücklich auf relationale Datenbanken wie diese immer noch des öfteren (wenn nicht gar fast ausschließlich) bei Projekten eingesetzt werden.

Vergleiche dazu z.B. diverse Dateisysteme, Notes oder LDAP.

Nunja. Deren Anwendungsgebiete sind aber meist auf recht spezielle Anwendungsgebiete (LDAP - klassischer Verzeichnisdienst; auch wenn es innerhalb dieser Anwendung recht flexibel ist) oder Systemgebunden (Dateisysteme).
Mit Notes kenne ich mich nicht genug aus. Soweit ich weiß ist das aber eher Groupware/Dokumentenmangement also auch eher speziell und wahrscheinlich nicht so ohne Weiteres programmierbar?! Zudem setzt es eine spezielle Software voraus. Bei Datenbanken ist man Dank ODBC/JDBC in Verbindung mit SQL zumindest in einem gewissen Rahmen ungebunden.

Wenn man den Begriff 'Datenbank' weit genug sieht, dann sind auch die Textdateien aus dem Ausgangsposting Datenbanken, allerdings mit einem schwachen, da fehleranfälligen, Verwaltungssystem dahinter.

Kommt darauf an, wie man diese Textdateien organisiert.
Datenbanken sind ja letzlich auch nur Dateien, wenngleich einiges an Verwaltungsaufwand mir durch die Datenbanksoftware abgenommen wird.

Ich sehe nur zwei Gründe für den Einsatz von Datenbanken.
Ich dagegen sehe nur einen Grund für den Einsatz von Datenbanken. Nämlich wenn man Daten mehr oder weniger Strukturiert ablegen muss/will;-)

*lächel* Auch eine Textdatei kann strukturiert sein (in XML) aber ich weiß schon, worauf Du hinaus willst.
Um jetzt nochmal den Bogen zu relationalen Datenbanken zu ziehen:
Solange man nur tabellarische Daten ablegen will (primitives Beispiel: Adressbuch), ist man mit relationalen Datenbanken gut bedient. Bei baumartigen Datenstrukturen muss man dagegen einige Verrenkungen anstellen. Und dann ist die Frage, ob dann noch eine rel. DB in der klassischen Verwendung das geeignete Speichersystem ist.

Gruß
   MichaelB

[Klaus Mock]

Hallo,

Ich bezog mich ausdrücklich auf relationale Datenbanken wie diese immer noch des öfteren (wenn nicht gar fast ausschließlich) bei Projekten eingesetzt werden.

Und ich versuchte Dir zu vermitteln, dass es eben nicht immer nur um relationales Systeme geht, wenn man von Datenbanken spricht;-)

Nunja. Deren Anwendungsgebiete sind aber meist auf recht spezielle Anwendungsgebiete (LDAP - klassischer Verzeichnisdienst; auch wenn es innerhalb dieser Anwendung recht flexibel ist) oder Systemgebunden (Dateisysteme).

Wenn ich micht nicht komplett irre, sind beides Beispiele für hierarchische Datenbanken.

Mit Notes kenne ich mich nicht genug aus. Soweit ich weiß ist das aber eher Groupware/Dokumentenmangement also auch eher speziell und wahrscheinlich nicht so ohne Weiteres programmierbar?!

Notes ist für mich immer ein gutes Beispiel für ein Datenbanksystem, dass recht gut mit unstrukturierten Daten umgehen kann. (Dafür ist es imho für die VErwaltung von strukturierten Daten weniger geeignet)

Zudem setzt es eine spezielle Software voraus.

Welches retaionale Datenbanksystem kennst Du, welches nicht spezielle Software voraussetzt?

Bei Datenbanken ist man Dank ODBC/JDBC in Verbindung mit SQL zumindest in einem gewissen Rahmen ungebunden.

Wenn denn die Datenbank ODBC/JDBC/ADO/DBI/BDE usw. unterstützt. Und nicht jede Datenbank kann mit SQL angesprochen werden (nicht einmal jede relationale Datenbank). Umgekehrt gibt es auhc für dieverse nicht-relationale Datenbanken die Möglichkeit sie mit SQL oder irgendeine der oben angeführten standardiersierten Zugriffsschichten anzusprechen.

Wenn man den Begriff 'Datenbank' weit genug sieht, dann sind auch die Textdateien aus dem Ausgangsposting Datenbanken, allerdings mit einem schwachen, da fehleranfälligen, Verwaltungssystem dahinter.
Kommt darauf an, wie man diese Textdateien organisiert.

Genau.

Datenbanken sind ja letzlich auch nur Dateien, wenngleich einiges an Verwaltungsaufwand mir durch die Datenbanksoftware abgenommen wird.

Sehe ich genauso.

Solange man nur tabellarische Daten ablegen will (primitives Beispiel: Adressbuch), ist man mit relationalen Datenbanken gut bedient.

wiederum kann ich dem nur zustimmen.

Bei baumartigen Datenstrukturen muss man dagegen einige Verrenkungen anstellen.

LDAP-Systeme bieten da imho einen guten Ansatz. Obwohl Datenbanken wie beispielsweise Oracle auch etwas Unterstützung für baumstrukturen in einem an  sich relationalen System bieten.
Problematischer als das Abbilden einer Baumstruktur sehe ich eher noch das Abbilden einer Sternstruktur in einem relationalen Datenbanksystem. Informix bietet hier afaik einen Ansatz, aber in den anderen, mir bekannten Systemen, sind Sternstrukturen nicht sauber abbildbar.

Und dann ist die Frage, ob dann noch eine rel. DB in der klassischen Verwendung das geeignete Speichersystem ist.

Wie ich schon sagte. Es muß nicht unbedingt relational sein und trotzdem ist es eine Datenbank.
Aber wir verzetteln uns schon wieder in Grundsatzdebatten.

Das Problem von Joey ist ja an sich die schlechte Datenverwaltung bei gleichzeitigen Zugriffen. Viele der heute üblichen Client/Server-DBMS-Lösungen bieten auch hier fertig umgesetzte Mechanismen, um das Problem damit in den Griff zu bekommen. Und das hatte imho Eternius bei seinem Posting im Sinn.

Eine der nächsten Fragen müsste sein, welches der möglichen Datenbanksysteme könnte geeignet sein, um die Datenstruktur von Joey gut abbilden zu können. Oder lohnt sich der Aufwand eines Umstiegs nicht, da mit etwas Nachbesserung in der Datenverwaltung (eventuell der Einbau eines Locking-Mechanismus, siehe Posting von Tom) die bestehende Lösung krisensicher(er) gemacht werden könnte.

Grüße
  Klaus

[MichaelB]

Hallo,

Ich bezog mich ausdrücklich auf relationale Datenbanken wie diese immer noch des öfteren (wenn nicht gar fast ausschließlich) bei Projekten eingesetzt werden.
Und ich versuchte Dir zu vermitteln, dass es eben nicht immer nur um relationales Systeme geht, wenn man von Datenbanken spricht;-)

Jaja ... das weiß ich auch. :-)
Ich wollte es einfach von Eternius nicht ganz unkommentiert stehen lassen. Denn seien wir mal ehrlich. Der größte Teil der Leute die das Wort "Datenbank" lesen denken an MySQL, SQL-Server oder Oracle. Halt die ganzen bekannten (aber eben relationalen) Sachen.

Nunja. Deren Anwendungsgebiete sind aber meist auf recht spezielle Anwendungsgebiete (LDAP - klassischer Verzeichnisdienst; auch wenn es innerhalb dieser Anwendung recht flexibel ist) oder Systemgebunden (Dateisysteme).
Wenn ich micht nicht komplett irre, sind beides Beispiele für hierarchische Datenbanken.

Das ist schon richtig. Aber beides nicht typische Datenbanken die man in Programmierprojekten einsetzt. Darauf wollte ich hinaus.

Mit Notes kenne ich mich nicht genug aus. Soweit ich weiß ist das aber eher Groupware/Dokumentenmangement also auch eher speziell und wahrscheinlich nicht so ohne Weiteres programmierbar?!
Notes ist für mich immer ein gutes Beispiel für ein Datenbanksystem, dass recht gut mit unstrukturierten Daten umgehen kann. (Dafür ist es imho für die VErwaltung von strukturierten Daten weniger geeignet)

Ja. Es ging mir wie gesagt um die Programmierung. Ist ja ganz nett wenn das System XYZ gut mit Daten umgehen kann oder auch nicht. Nur hab ich als Programmierer davon nicht viel, wenn ich es nicht mehr oder weniger direkt ansprechen kann.

Zudem setzt es eine spezielle Software voraus.
Welches retaionale Datenbanksystem kennst Du, welches nicht spezielle Software voraussetzt?

Menno. Was ich meinte wird doch in den nächsten Zeilen sichtbar.

Ausserdem gibt es noch die embedded-DB-Systeme die nur über eine Bibliothek angesprochen werden. Dann brauchst Du quasi nur noch Dateizugriffsrechte und keinerer laufende Dienste/installierte Software.

Bei Datenbanken ist man Dank ODBC/JDBC in Verbindung mit SQL zumindest in einem gewissen Rahmen ungebunden.
Wenn denn die Datenbank ODBC/JDBC/ADO/DBI/BDE usw. unterstützt. Und nicht jede Datenbank kann mit SQL angesprochen werden (nicht einmal jede relationale Datenbank). Umgekehrt gibt es auhc für dieverse nicht-relationale Datenbanken die Möglichkeit sie mit SQL oder irgendeine der oben angeführten standardiersierten Zugriffsschichten anzusprechen.

Sicher. Du hast mit allem Recht. Fakt ist aber, daß ich mit ODBC/JDBC und SQL ziemlich viele DB-Systeme ansprechen kann. Andere Zugriffsschichten sind bei weitem nicht so verbreitet. Und darum ging es mir.

Bei baumartigen Datenstrukturen muss man dagegen einige Verrenkungen anstellen.
LDAP-Systeme bieten da imho einen guten Ansatz.

LDAP klingt von der Sache her schon nicht schlecht. Nur welcher Provider stellt das schon zur freien Verwendung Verfügung.
Und hat man selbst einen Server, gibt es wiederum Alternativen. Obwohl LDAP dadurch das es einen gewissen Standard darstellt trotzdem sehr interessant ist.
Komischerweise zieht es kaum einer als reinen Datenspeicher für Programmierprojekte in Betracht.

Obwohl Datenbanken wie beispielsweise Oracle auch etwas Unterstützung für baumstrukturen in einem an  sich relationalen System bieten.

Ja. Man versucht sich daran. Elegant ist das aber nicht.

Problematischer als das Abbilden einer Baumstruktur sehe ich eher noch das Abbilden einer Sternstruktur in einem relationalen Datenbanksystem. Informix bietet hier afaik einen Ansatz, aber in den anderen, mir bekannten Systemen, sind Sternstrukturen nicht sauber abbildbar.

Worin unterscheiden sich den Sternstrukturen und Baumstrukturen ?

Das Problem von Joey ist ja an sich die schlechte Datenverwaltung bei gleichzeitigen Zugriffen. Viele der heute üblichen Client/Server-DBMS-Lösungen bieten auch hier fertig umgesetzte Mechanismen, um das Problem damit in den Griff zu bekommen. Und das hatte imho Eternius bei seinem Posting im Sinn.

Es ging mir nicht so sehr um Joeys Problem im Speziellen, sondern mehr um Datenbanken im Allgemeinen.
Sorry Joey, dass ich dazu Dein Thread missbraucht habe.

Gruß
  MichaelB

[Ilja]

yo,

datenbanken haben sich aus bestimmten problematiken in der informatik entwickelt und der hauptgrund sie einzusetzen ist die datenunabhängigkeit. das ist das wichtigste kriterium für datenbanken, wobei es natürlich noch mehr sinnvolle funktionen gibt, die ein dbms abdeckt, zum beispiel wenn mehrere gleichzeitig auf die selben daten zugreifen wollen. und scheinbar geht es ja genau um diese problematk bei ihm.

das problem, dass der ursprungsposter hat, würde sich also scheinbar mit datenbanken beheben lassen. letztlich sind datenbanken nichts anderes als gespeicherte infos in irgendwelchen dateien. der grosse unterschied ist der, dass man eben nicht direkt auf diese daten (zb. textdatei) zugreift, sondern über ein dbms. viele schreien gleichen auf, overhead, geschwindigkeit, etc. aber die vorteile von solch einem "flaschenhals" sind für firmen elementar.

meiner meinung nach macht es immer sinn, die jeweiligen daten in datenbanken abzuspeichern. sicherlich muss man sich in die thematik ein wenig reinarbeiten. aber die arbeit lohnt sich, da man dann sehr schnell und effektiv seine daten verwalten und abrufen kann.

Ilja

[MichaelB]

Hallo,

datenbanken haben sich aus bestimmten problematiken in der informatik entwickelt und der hauptgrund sie einzusetzen ist die datenunabhängigkeit. das ist das wichtigste kriterium für datenbanken,

Das ist in der Tat ein _sehr_wichtiges Kriterium.

das problem, dass der ursprungsposter hat, würde sich also scheinbar mit datenbanken beheben lassen. letztlich sind datenbanken nichts anderes als gespeicherte infos in irgendwelchen dateien. der grosse unterschied ist der, dass man eben nicht direkt auf diese daten (zb. textdatei) zugreift, sondern über ein dbms. viele schreien gleichen auf, overhead, geschwindigkeit, etc. aber die vorteile von solch einem "flaschenhals" sind für firmen elementar.

Ich stimme Dir zu. Ich würde auch ein DBMS bevorzugen. Die Frage ist nur, ob es ein relationales DBMS sein muss (wie bei dem Wort "Datenbank" implizit sehr oft angenommen).

Gruß
  MichaelB

[Klaus Mock]

Hallo,

Nunja. Deren Anwendungsgebiete sind aber meist auf recht spezielle Anwendungsgebiete (LDAP - klassischer Verzeichnisdienst; auch wenn es innerhalb dieser Anwendung recht flexibel ist) oder Systemgebunden (Dateisysteme).
Wenn ich micht nicht komplett irre, sind beides Beispiele für hierarchische Datenbanken.
Das ist schon richtig. Aber beides nicht typische Datenbanken die man in Programmierprojekten einsetzt. Darauf wollte ich hinaus.

Abgesehen davon, dass alles, was irgendwann einmal an Software gemacht wurde, für mindestens ein Programmierprojekt entwicktelt wurde, stimmt es für LDAP schon, dass es nicht zu den beliebtesten Protokollen in Programmierprojekten gehört. Aber ich persönlich kenne doch relativ viele Programme, die auf Dateisysteme schreibend und lesend zugreifen *g*.

Ja. Es ging mir wie gesagt um die Programmierung. Ist ja ganz nett wenn das System XYZ gut mit Daten umgehen kann oder auch nicht. Nur hab ich als Programmierer davon nicht viel, wenn ich es nicht mehr oder weniger direkt ansprechen kann.

Natürlich kann man Notes auch programmieren. Afaik gibt es sogar eine SQL-Schnittstelle und auch ODBC/JDBC-Treiber http://www-10.lotus.com/ldd/toolkits. Wie gut das ganze funktioniert, weiss ich nicht. Aber darum geht es Dir ja nicht, denke ich mal.

Zudem setzt es eine spezielle Software voraus.
Welches retaionale Datenbanksystem kennst Du, welches nicht spezielle Software voraussetzt?
Menno. Was ich meinte wird doch in den nächsten Zeilen sichtbar.

s.o.

Ausserdem gibt es noch die embedded-DB-Systeme die nur über eine Bibliothek angesprochen werden. Dann brauchst Du quasi nur noch Dateizugriffsrechte und keinerer laufende Dienste/installierte Software.

Ja, aber ich denke doch, dass solche System eher die Ausnahme sind.

Fakt ist aber, daß ich mit ODBC/JDBC und SQL ziemlich viele DB-Systeme ansprechen kann. Andere Zugriffsschichten sind bei weitem nicht so verbreitet. Und darum ging es mir.

Ich will ja nicht lästig sein, aber hast Du Dir DBI und dessen Treiber-Umfang einmal genauer angesehen(http://search.cpan.org/modlist/Database_Interfaces/DBD)?
Und das Perl und dessen Datenbankzugriffsschicht nicht verbreitet ist, kann man so nicht sagen. Andererseits ist Perl wahrscheinlich für Dich nicht relevant, da es eine Scriptsprache ist, und daher für 'richtige' Programmierarbeit nicht in Frage kommt, oder so ähnlich *g*?

Worin unterscheiden sich den Sternstrukturen und Baumstrukturen ?

Baumstrukturen sind ja hierarchisch angeordnet. Mit einer ID und einer Parent-ID kann man an sich einen Baum ganz gut auch in relationalen Systemen abbilden, auch wenn die Rekursion Probleme bereitet.

Will man dagegen beispielsweise Objekte, die einerseits gleiche Merkmale aufweisen, andererseits jedoch auch unterschiedliche Eigenschaften haben, dann funktioniert das in relationalen Datenbanken nicht wirklich.

Ein (vielleicht nicht unbedingt praxisnahes) Beispiel:

Nehmen wir an wir haben ein System das Dokumente, Projekte, Aufträge und Kunden verwaltet. All diese Objekte haben ganz unterschiedliche Eigenschaften. Für das Zugriffsberechtigungssystem will man aber alle Objekte gemeinsam verwalten können. Ich kann entweder für jeden Objekttyp zusätzliche Berechtigungsstrukturen aufbauen und die Abfragen so gestalten, dass sie eine gemeinsame Sicht ermöglichen. Allerdings sind dann Änderungen am Berechtigungssystem für alle Objekttypen nachzuziehen. Oder aber ich entwickle eine gemeinsame Berechtigungsverwaltung, in der alle Objekte mittels ID und Objekttyp angesprochen werden, was allerdings zur Folge hat, dass ich keine Constraints mehr verwenden kann. (Ausser bei Informix, die afaik solche Foreign-Keys auf unterschiedliche Tabellen kann).

Wenn Du einen eleganten Lösungsansatz parat hast, wäre ich sehr interessiert daran.

Es ging mir nicht so sehr um Joeys Problem im Speziellen, sondern mehr um Datenbanken im Allgemeinen.

Mir auch;-) Wir beide haben anscheinend nur unterschiedliche Auffassungen von 'im Allgemeinen'.

Sorry Joey, dass ich dazu Dein Thread missbraucht habe.

Keine Sorge, Threaddrifts sind hier normal.

Grüße
  Klaus

[MichaelB]

Hallo Klaus,

Aber ich persönlich kenne doch relativ viele Programme, die auf Dateisysteme schreibend und lesend zugreifen *g*.

Ja. Aber ein Dateisystem würde ich nicht unbedingt als ... Datenbank im engeren Sinne auffassen.
So gibt es nur beschränkt Objekttypen und der Verwaltung liegt weitestgehend in meiner Hand (was natürlich auch ein Vorteil sein kann).

Ausserdem gibt es noch die embedded-DB-Systeme die nur über eine Bibliothek angesprochen werden. Dann brauchst Du quasi nur noch Dateizugriffsrechte und keinerer laufende Dienste/installierte Software.
Ja, aber ich denke doch, dass solche System eher die Ausnahme sind.

Dennoch eine recht interessante Alternative. Da man sie praktisch ohne Vorraussetzungen einsetzen kann aber trotzdem Features hat wie bei einer "richtigen" Datenbank.

Ich will ja nicht lästig sein, aber hast Du Dir DBI und dessen Treiber-Umfang einmal genauer angesehen(http://search.cpan.org/modlist/Database_Interfaces/DBD)?
Und das Perl und dessen Datenbankzugriffsschicht nicht verbreitet ist, kann man so nicht sagen.

Ja ok.Zählen wir DBI auch noch dazu. :-)
Mir ging es um die Sache. Wieviele Schnittstellen es gibt und wie die heißen ist irrelevant.
Fakt ist das es gute Gründe gibt auf ein DB-System zu setzen, für dass verbreitete Schnittstellen existieren. Darauf wollte ich hinaus.

Andererseits ist Perl wahrscheinlich für Dich nicht relevant, da es eine Scriptsprache ist, und daher für 'richtige' Programmierarbeit nicht in Frage kommt, oder so ähnlich *g*?

Nunja. Für kleinere Sachen ist es ja ganz nett. Hat halt Eigenschaften die es bis zu einer gewissen Programmgröße recht nützlich sind aber über einer gewissen Programmgröße hinaus ungeeignet machen.
Zudem bekommt Perl zunehmend Konkurrenz. Besonders Ruby und Python haben sich in den letzten Jahren zu einer mächtigen und vorallem sehr attraktiven Alternative entwickelt.

Worin unterscheiden sich den Sternstrukturen und Baumstrukturen ?
Baumstrukturen sind ja hierarchisch angeordnet. Mit einer ID und einer Parent-ID kann man an sich einen Baum ganz gut auch in relationalen Systemen abbilden, auch wenn die Rekursion Probleme bereitet.

Will man dagegen beispielsweise Objekte, die einerseits gleiche Merkmale aufweisen, andererseits jedoch auch unterschiedliche Eigenschaften haben, dann funktioniert das in relationalen Datenbanken nicht wirklich.

Ein (vielleicht nicht unbedingt praxisnahes) Beispiel:

Nehmen wir an wir haben ein System das Dokumente, Projekte, Aufträge und Kunden verwaltet. All diese Objekte haben ganz unterschiedliche Eigenschaften. Für das Zugriffsberechtigungssystem will man aber alle Objekte gemeinsam verwalten können. Ich kann entweder für jeden Objekttyp zusätzliche Berechtigungsstrukturen aufbauen und die Abfragen so gestalten, dass sie eine gemeinsame Sicht ermöglichen. Allerdings sind dann Änderungen am Berechtigungssystem für alle Objekttypen nachzuziehen. Oder aber ich entwickle eine gemeinsame Berechtigungsverwaltung, in der alle Objekte mittels ID und Objekttyp angesprochen werden, was allerdings zur Folge hat, dass ich keine Constraints mehr verwenden kann. (Ausser bei Informix, die afaik solche Foreign-Keys auf unterschiedliche Tabellen kann).

Nunja. Das ist das Problem bei solchen Datenbanken. In einer OO-Datenbank würde ich jetzt einfach eine neue Oberklasse einführen (oder eine evtl.  bestehende Oberklasse erweitern) mit den neuen Eigenschaften (hier Zugriffsberechtigungen).

Wenn Du einen eleganten Lösungsansatz parat hast, wäre ich sehr interessiert daran.

Rein auf Datenbankbasis wird es in Deinem Beispiel schwierig diese Eigenschaften im nachhinein einzuführen. Relationale Datenbanken sind oft zu unflexibel. Deshalb sollte ihr Einsatz wohlüberlegt sein.

Es ging mir nicht so sehr um Joeys Problem im Speziellen, sondern mehr um Datenbanken im Allgemeinen.

Mir auch;-) Wir beide haben anscheinend nur unterschiedliche Auffassungen von 'im Allgemeinen'.

:-)

Gruß
   MichaelB