Frage: beste DB-Struktur

[Serow]

Hi,
ich möchte ein Programm schreiben, das auf eine MySQL-Datenbank zugreift. In der DB sollen Daten über bestimmte Objekte gespeichert werden. Jedes dieser Objekte soll kommentiert werden können von den Usern die das Programm benutzen. Die Anzahl der Kommentare ist also unbestimmt. Wie löse ich das am Besten? Ich kann ja nicht für jeden Kommentar die Anzahl der Spalten der Tabelle erhöhen etwa so:

Name          Info1        Info2      Info3      Kommentar1      Kommentar2        ...

Was mir noch einfällt ist für jedes Objekt in der Tabelle eine eigene anzulegen in der dann die Kommentare stehen. Der Name der "Details-Tabelle" muss dann irgendwo im Datensatz des Objekts zu finden sein.
Aber bevor ich das in Angriff nehme wollte ich eben mal fragen obs nicht doch einfacher geht. Bin nicht so bewandert auf dem Gebiet Datenbanken.
Achja: Als Sprache nehme ich Java. Kann man eigentlich Objekte in MySQL serialisieren?

mfg
Serow

 

[LX]

Praktisch wäre eine ID für jedes Objekt. Dann kannst du die Kommentare dazu in eine weitere Tabelle packen und mittels der ID als Fremdschlüssel darauf zugreifen. Ich stelle mir das in etwa so vor:

tab objekt
# id         <---+
  name           |
  info1          |
  info2          |
  info3          |
                 |
tab kommentar    |
# id             |
* id_objekt   ---+
  kommentar

Damit ist der Anzahl deiner Kommentare keine Grenze gesetzt.

Wegen der Serialisierung: Lass das Java machen und packe das Ergebnis in die Datenbank.

 

[Serow]

Ok, das klingt gut, so brauche ich nicht für jedes Objekt eine eigene Tabelle mit Kommentaren.
Was glaubst du ist performanter? Deine Methode oder alle Kommentare in einem Objekt in die erste Tabelle serialisieren?

 

[LX]

Kommt drauf an, was du unter einem "Objekt" verstehst. Wenn du damit ein Objekt mit Methoden und Eigenschaften meinst, dann wirst du um Serialisierung nicht rumkommen, denn Methoden lassen sich anderweitig in der Datenbank nicht unterbringen. Wenn es dir aber nur um Eigenschaften geht, dann würde ich die Tabelle entsprechend erweitern um eine Spalte je Eigenschaft (vorausgesetzt, deine Objekte haben alle die gleichen Eigenschaften, nur unterschiedliche Werte).

 

[Serow]

Ich dachte an die Kommentare.
Einfach eine Liste von Strings in ein Object packen und es serialisieren.

Name  |  Info1  |  Info2  |  Info3  |   Comments

In dir Spalte "Comments" würde dann das Object mit den Strings reinkommen.

mfg
serow

 

[LX]

Von welcher Art "Objekt" du nun sprichst, ist aber immer noch nicht klar.

Die Frage, die sich stellt, ist: was willst du mit der Datenbank erreichen?

Wenn du nur eine persistente Datenhaltung willst, kannst du deine Objekte auch in Dateien aufs Dateisystem packen. Eine Datenbank lohnt sich erst dann, wenn du die Objekte strukturieren willst, wenn du auf bestimmte Eigenschaften Abfragen machen willst etc. Aber um beispielsweise auf einen einzelnen Kommentar zurückzugreifen, muss der auch separat in der Datenbank zu finden sein und nicht irgendwo zusammengepappt mit allen möglichen anderen Informationen in einer serialisierten Datenstruktur, von der MySQL keine Ahnung hat.

 

[Serow]

Also ich glaube immer wenn ich von "Objekt" gesprichen habe ist das gemeint, zu dem die Tabelle

Name | Info1 | Info2 | etc

gehört. Jede Zeile in dieser Tabelle würde dann ein "Objekt" sein. Wenn ich von "Object" spreche, meine ich eine von "Object" erbende Klasse in Java, die in der DB serialisiert werden soll.

Eine DB brauche ich allein deshalb schon, weil das Programm von mehreren Usern benutzt werden soll, die auch selber Daten ändern können, was aber für die anderen wiederum sichtbar sein soll. Also komme ich um eine DB die online ist nicht herum. Wenn nach diesen Kommentaren gefragt werden soll, müssen sowieso immer ALLE abgefragt werden, die dieses "Objekt" betreffen. Deswegen dachte ich man könnte sie alle in ein "Object" packen und serialisieren. Dann könnte man sich die zweite Tabelle sparen. Wenn jetzt aber die Leistung start darunter leiden würde, müsste ich mich ja für die andere Lösung entscheiden.
Also, kann jemand sagen wie das ist? Die Kommentare können locker 2MB größe String sein oder so. Meine Überlegung sieht jetzt so aus: Wenn es wirklich soweit kommen sollte, dass die Kommentare 2MB beanspruchen, sind es ja sooo viele, dass sie sich sowieso niemand alle anschaut. Deswegen wäre es vielleicht sinnvoller nur die letzten 100 Kommentre abzurufen, was mit der Serialisierungs-Variante ja nicht möglich wäre.
Liege ich mit dieser Einschätzung richtig?

mfg
serow

 

[Unicate]

2. Normalform ist besser:
2 Tabellen:

1. Objekt:
-id
-name

2. Infos/Kommentare
-id
-objektid
-kommentar

Die Objekt ID bekommt halt immer die id des Objektes aus der Objekte Tabelle

lässt sich auch sehr gut durch nen JOIN befehl im SQL auslesen