DB-Neuling sucht Gründe für PostgreSQL

Hallo zusammen!

Kurz zu mir: ich bin neu auf dem Gebiet der Datenbanken. Im Rahmen der Diplomarbeit möchte ich eine Datenbank entwickeln, welche unter anderem mit Daten aus einem Delphi-Programm gefüttert wird. Der Zugriff auf die Daten soll vorerst nur mit Web-Interface (also PHP) erfolgen. Bei der Wahl der “richtigen” DB komme ich momentan absolut nicht weiter…

Kurz zur Datenbank an sich:
Sie enthält ein Knoten-Kanten-Modell (Topologie) als Abbild einer realen Verkehrsinfrastruktur. Auf den Kanten liegen Elemente unterschiedlichen Typs (mind. 20 verschiedene), wobei die Grundeigenschaften aller Elemente in einer Oberklasse zusammengefasst sind. Das Datenmodell nutzt also Vererbung.

Erwarteter Datenumfang:
Lässt sich nicht so einfach abschätzen. Verglichen mit dem, was ich hier so lese ist dieser “relativ gering”. (ist ja auch noch mitten in der Entwicklung, d.h. Anzahl der Zugriffe ist auch noch nicht abschätzbar)

Derzeitiger Stand:
Ich habe das gemacht, was noch halbwegs unabhängig von der Implementierung ist:

  1. Bücher gelesen (relationale und bissl objektrelationale DB)
  2. Datenmodell als UML-Klassendiagramm entworfen, Kardinalitäten und Domänen bestimmt,…
  3. Das Ganze normalisiert.

Ich denke die Anzahl der Tabellen hält sich auch nach der Normalisierung in Grenzen.
Nun meine Frage: Warum sollte ich PostgreSQL nehmen? Bis jetzt habe ich den Eindruck, dass alle Open-Source-DB-Systeme meinen Ansprüchen genügen. Dabei lege ich auch Wert auf die Wartung/Modifizierung des Datenmodells und der einfach Umsetzung in der DB.
Die Vererbung hab ich ganz gut im relationalen Modell abbilden können. Also was bringt das “objektrelationale” noch so für Vorteile? Oder sollte ich die Motivation für PostgreSQL woanders suchen?

Hab langsam das Gefühl, dass ich durch lesen nicht mehr weiterkomme. Das Problem liegt wohl in meiner mangelnden Erfahrung. Also hoff ich, dass ihr mir weiterhelfen könnt?
DANKE SCHON IM VORAUS!

Hallo benwen,

da Du in deinem Beitrag von Topologie und Knoten-Kanten-Modell sprichts, hast Du schon mal über GIS nachgedacht. PostgreSQL kann mit PostGIS erweitert werden. Damit solltest Du Deine Software mit weit weniger Aufwand erstellen können.

Hier noch ein Link mit weiteren Informationen: http://postgis.refractions.net/ .



mfg

fristo

Ich würde grob vermuten, das dir PostGIS nützlich sein könnte. Zu PostGIS selbst gibt es auch eine Routing-Erweiterung, die in einem Post von mir verlinkt ist. Bin aber noch nicht zum Testen gekommen, da es für mein Problem keine Lösung war :wink:
Auch Topologie wird im Rahmen von PostGIS behandelt werden, allerdings waren die Sachen alle noch in einem sehr frühen Stadium, als ich das letzte mal darüber gestolpert bin.
PostGIS ist eine Erweiterung, die sonst schlicht für keine andere DB frei zu haben ist und die vergleichbar mit Oracle Spatial oder IBMs Spatial Extender ist.
Sonstige Gründe für PG:
Schnell, stabil, weitestgehend SQL-konform, BSD-Lizenz.

Gruß Uwe

Danke für eure Antworten!

Ich hab einen Blick auf PostGIS geworfen. Ganz überzeugt bin ich nicht davon, dass ich das brauche, da die Art der Speicherung der Topologiedaten in meinem Modell aufgrund der Konformität zu anderen Standards/Schnittstellen schon vorgegeben ist. Weiterhin benötige ich die Funktionalität von PostGIS, die zwar beeindruckend ist, voraussichtlich nicht.
Also tolle Sache, aber wohl nicht notwendig für meine Ansprüche.

Vielmehr steht hier für mich die Entscheidung: relational oder objektrelational an, unter die Bedingung: Open Source.
Hier würde mich die Meinung idealerweise von Personen, die auch mit kommerziellen objektrelationalen Systemen wie DB2 arbeiten, interessieren, ob PostgreSQL überhaupt ein guter Kandidat für die Ausnutzung der Vorteile von objektrelationalen DB-Systeme geeignet ist. Zum Beispiel habe ich “gehört”, dass man den Objekten keine Funktionen/Methoden zuweisen kann in PostgreSQL. Stimmt das so? Gibt es nochmehr Unterschiede zu kommerziellen Systemen? Und tut es nicht in meinem Fall auch eine stinknormale relationale DB (Firebird, Mysql,…)?

Bin immer noch ratlos. Ich brauche Argumente, aber hab keine Zeit mehrere Systeme auszuprobieren, möchte aber auch nicht bei der Implementierung festellen müssen, das das System ungeeignet ist.

Könnt ihr mir helfen? Gruß und Danke.benwen

Edit1: Eine Anforderung habe ich vergessen: Ich muss zu den Elementen korrespondierende Bilddaten speichern. Wie speichere ich am besten Bilddaten ab in einer Datenbank? Geht das überhaupt mit relationalen DB?
Edit2: Ein Grund, warum ich zuerst gar nicht richtung PG gedacht hatte, war das Ergebnis aus dem c’t-Datenbankkontest im Jahr 2005. Dort scheint ja MySQL alles abgeräumt zu haben. Liegt das nur an der Qualität der Implementierung/OPtimierung?

Morgen!

zu Edit 1:
Klar geht das, aber ist es sinnvoll? AFAIK werden BLOBs sowieso extern abgelegt. Ich habe diese Anforderungen auch, und hinterlege nur den Pfad. Auch um noch Zugriff über das fFilesysten zu haben.

Edit2:
IMHO werden Tests immer gern zu Gunsten vom MySQL hingebogen, indem halt das getestet wird was MySQL gut kann. Schnell ist es nämlich nur wenn du auf alles verzichtest, was eine DB ausmacht. Wenn du mal auf der Basis der Fähigkeiten von PostgreSQL testet, sieht es anders aus. Und der Test ist auch veraltet, in einer der letzten iXe sah es nämlich anders aus :wink:

Gruß Uwe

Aha, ich hab jetzt PG installiert und begonnen die DB umzusetzen.

Eine Frage hätte ich noch bezügliche der Vererbung:
Was bringt es mir für die Vererbungsmethode in PG für Vorteile gegenüber dem Ansatz, für jede Subklasse eine neue Tabelle anzulegen und über Fremdschlüssel auf die Oberklasse zu beziehen?

Eine weitere Frage zu den Arrays:
In meinem Datenmodell kommen Array-Typen für Attribute vor. Ist es wirklich besser, diese als Array in der DB umzusetzen anstatt für jedes Attribut eine eigene Tabelle anzulegen?

Gruß
benwen

So viel ich weiss gibt die Verebung folgende Vorteile:

  • Du hast dir einen Key gespart :rolleyes:
  • Du brauchst keine Sub-Datarecords einzulesen/speichern/löschen, sondern hast mit einem Read direkt alles zusammen.
  • bessere Performance beim Lesen/schreiben/löschen
  • wenn du bei einer Referenzierung über den Key gehst, is es nicht möglich für Tabelle A zu sagen: “Hier soll das und das Feld z.B. NOT NULL sein”, während für Tabelle B alles beim alten bleibt.
    (Schwierig auszudrücken…)
    Also Tabelle A (Felder a0,a1) ist die ElternKlasse. Tabelle AX und AY erben jeweils von A.
    In AX kann ich dann sagen Feld a0 ist ein Pflichtfeld, In AY kann ich sagen a1 ist ein Pflichtfeld.
    Wenn ich bei der bekannten 1:1 Verknüpfung das mache, müßte ich Tabelle A sagen welche Felder “NOT NULL” sind und hätte dann das Problem, dass dies dann auch direkt für die Tabellen AX und AY gilt.