nicht angemeldet
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