Problem beim Datenbankentwurf

[murraene]

Hi erstmal,

ich schein grad ein wenig auf dem Schlauch zu stehen, vielleicht könnt ihr mir helfen.

Ich versuche gerade eine Datenbank zu entwerfen, die verschiedene Experimente verwaltet. Es soll verschiedene Experimenttypen geben die immer wieder duchgeführt werden aber man soll auch neue Experimenttypen anlegen können, die aber alle verschiedene Anzahlen von Feldern haben können.

Für jeden Experimenttyp eine eigene Tabelle? Das würde über kurz oder lang zu einer Überflutung an Tabellen führen. Kann man das eleganter lösen?

Überlegung:

Experiment-Typ Eigenschaft
1 - hat Eigenschaft 1
2 - hat Eigenschaft 2
3 - hat Eigenschaft 3

Eigenschafts-Typ
1 - Beschreibung 1
2 - Beschreibung 2
3 - Beschreibung 3

Kommt aber deshalb nicht in Frage, da die einzelnen Eigenschaften von verschiedenen Datentypen sein können. Es soll ja beispielsweise nach Zahlenwerten sortiert werden können. Kann auch vorkommen, dass eine Eigenschaft ein Dokumentenanhang sein kann.

Wie geh ich da am geschicktesten ran?

Vielen Dank schon mal!

[dibo33]

Das hier hatte ich mir überlegt:

Nö, Tom aus dem anderen Forum hat sich das überlegt.

Für dein Vorhaben ist ein relationales Datenbanksystem sehr schlecht geeignet, du solltest dich mal in Richtung objektorientiertes Datenbanksystem oder NoSQL Datenbanksystem orientieren.

[murraene]

Nö, Tom aus dem anderen Forum hat sich das überlegt

Hättest du weitergelesen, hättest du mitbekommen, dass ich diesen Ansatz schon vor Toms Überlegung durchgespielt hatte, mit dem in meinem Eingangsbeitrag erwähnten Ergebnis.

Trotzdem danke für den Vorschlag - bin aber auf MySQL festgenagelt

[dibo33]

bin aber auf MySQL festgenagelt

In dem Fall kann es hier keine andere Vorschläge geben welche nicht schon bei SelfHTML gegeben wurden.

[Ralf Jansen]

Was für eine Art von Abfragen willst du den auf diese Daten machen? Davon hängt ab welche Struktur den Sinn macht.

Wenn mein Vorstellung von Experimenttyp richtig ist läuft es doch nur darauf hinaus ganze Experimente aus der DB zu laden oder in die DB zu schreiben richtig? Dann lohnt es sich eh nicht die Daten in eine relationale Form zu zerlegen. Dann würde ich eine Platte Tabelle machen und die gesammelten Daten zu einem Experimenttyp in ein einzelnes Feld schreiben und das auseinandernehmen der Anwendung vor der Datenbank überlassen.


PS. Dir ist klar das Crossposts unbeliebt sind oder? Wenn woanders ebenfalls dieses Thema behandelt wurde und bereits mehr Details besprochen wurden fände ich es ausgesprochen ärgerlich wenn du das hier nicht erwähnst und ich völlig umsonst wieder bei null beginne. Also verlinke den anderen Beitrag bevor ein Admin zur Strafe diesen Thread dicht macht.

[fanderlf]

Das Problem ist ja anscheinend dass Du versuchst Instanzen eines Abstrakten Typs, in Deinem Fall Experiment, in der DB abzubilden. Generell lassen sich solche Strukturen durchaus in der Datenbank abbilden:

Table per Class: Das wäre der Ansatz den Du beschrieben hast. Eignet sich am Besten wenn die Daten extrem unterschiedlich sind.

Table per Subclass: Gemeinsame Daten werden in einer Tabelle festgehalten die z.B. auch die ID enthält welche Subclass hier ausgewählt ist

Table per Class hierarchy: Hier gibt es eine gemeinsame Tabelle für alle Subklassen. Eignet sich am Besten wenn es nicht allzu viele Daten werden. Wie bei Table per Subclass bestimmt auch hier eine ID um welchen konkreten Experimenttyp es sich handelt.

Ich hab so etwas auch schon in NHibernate abgebildet.

Hier mal etwas Doku zu Hibernate und diesen Patterns:
http://docs.jboss.org/hibernate/orm/...heritance.html

Achja... natürlich ist dann nicht immer jede Spalte belegt, denn nicht jedes Experiment hat jede Eigenschaft. Aber in Zeiten in denen Speicher nicht mehr viel kostet würde ich das erstmal beiseite lassen.

[Falk Prüfer]

Crossposting => Close!