Guest Christoph

Hier fehlt jetzt die Rechnungsposition - und (abgesehen davon ob man das überhaupt für ein sinnvolles Attribut hält) da wird es eigentlich interessant.

Ich habe mich primär nur auf PKs und FKs konzentriert. Un klar warum sollte die Position nicht sinvoll sein? Wenn du eine Rechnung mehrmals anschaust möchte man in der Regel ja nicht das die Einträge immer durcheinander angezeigt werden (Sortierung von der Datenbank kann generell random sein).

Quote

Also zwischen rechnung und die beiden M:N Tabellen eine weitere Tabelle, die die Position enthält? Oder position in beiden M:N Tabellen mit einem trigger, der überprüft, dass(id_rechnung, position) über beide Tabellen unique ist?

Ich würde keins von beiden machen. Wenn es zwei komplett unterschiedliche Tabellen sind mit unterschiedlichen Daten halte ich es generell für ziemlich schlecht unterschiedliche Daten in einer tabelle anzuzeigen.

Möchte man eine Sortierung wirklich über beide Tabellen machen, dann würde ich vor den beiden N:M Tabellen nochmals eine Tabelle hinzufügen die die Sortierung macht, die dann entweder auf die eine oder andere Tabelle verweist. Aber sowas halte ich nicht gerade für ein schönes Design.

Quote

Oder eine tabelle rechnung_element von der rechnung_artikel und rechnung_stundenzettel erben könnten?

Wenn Relationale Datenbanken sowas wie vererbung verstehen würden könnte man darüber vielleicht sprechen.

Aber sowas bieten reine Relationale Datenbanken wie z.B. MySQL nicht an. PostgreSQL versteht aber vererbung, st aber auch eine ORDBMS. Ich würde meine Anwendung in der Regel aber nicht so schreiben das sie nur auf PostgreSQL läuft.

Aber unabhängig davon sagte pktm ja das in beiden Tabellen komplett unterschiedliche Daten gespeichert werden. Dafür ist vererbung auch nicht gedacht. vererbung ist ein Mittel um Klassen spezifischer zu machen. Nicht um komplett unabhängige Sachen irgendwie zusammenzubringen.