n:m Beziehung

[chunky]

Hallo.

N:M-Beziehungen werden mit einer "Zwischentabelle" modelliert.
Wenn ich nun Schauspieler, Kinofilme und TV-Serien habe...
Ein Schauspieler kann in mehreren Kinofilmen und mehreren TV-Serien mitspielen.
Ebenso enthalten Serien und Kinofilme mehrere Schauspieler.
Man braucht also eine M:N-Beziehung.

Kann ich das nicht so lösen?



Die Zwischentabelle hat hier nur den Schauspieler als Primary Key bekommen. Kinofilm oder Serie kann jeweils Null sein, je nach dem ob der Schauspieler im Film oder einer Serie mitspielte.
Problem: Es dürfen natürlich nicht beide Null sein, sonst macht das keinen Sinn.

Muss ich für Kinofilme und TV-Serien getrennte Zwischentabellen erstellen?
Oder kann ich das nicht in eine Tabelle "hat_mitgespielt_in_Film_oder_Serie" packen?

[thomas_w]

Problem: Es dürfen natürlich nicht beide Null sein, sonst macht das keinen Sinn.

Muss ich für Kinofilme und TV-Serien getrennte Zwischentabellen erstellen?
Oder kann ich das nicht in eine Tabelle "hat_mitgespielt_in_Film_oder_Serie" packen?

Also ich tendiere zu zwei Zwischentabellen. Eine klare Trennung. Zum Einen hast Du dann das Problem mit dem NULL los, zum Anderen läuft die Abfrage sonst immer auf ein ODER hinaus ".. id = tvserie_id OR id = kinofilm ..". Das könnte aus Performance-Sicht nachteilig sein.

Grüße
Thomas

[chunky]

Okay, danke für die Antwort. Es in eine Tabelle zu packen hat zu viele Nachteile.

An einer anderen Stelle habe ich ein ähnliches Problem:



Ich bin mir unsicher, ob das der richtige Weg ist, um Favoriten zu modellieren.
Der User (Member) der Webseite kann mehrere Favoriten haben. Ein Favorit kann auch von mehreren Nutzern gleichzeitig favorisiert werden. Deshalb die M:N-Beziehung rechts.
Ein Favoriteintrag soll entweder aus einem Kinofilm, einer Serie, einer Theateraufführung oder sonstigen Events bestehen.

Das scheint mir keine gute Art zu sein, um Favoriten zu modellieren.
Ich weiss jedoch nicht, wie ich es besser machen könnte...

Dieselben Probleme habe ich mit den Tabellen für Tags und Kommentare. Ist es besser eine eigenständige Tabelle für jede Kommentarart zu erstellen? (z.B. Kommentare für Kinofilme, TVSerien, etc.)

[thomas_w]

Die Tabelle FAVORITEN und MEMBER_HAS_FAVORITEN sind meiner Meinung nach unnötig. Vermutlich genügt es MEMBER_FAVORITEN_KINOFILME als Zwischentabelle zu definieren. Das Gleiche gilt für MEMBER_FAVORITEN_TVSERIEN etc.

Ist das Datenmodell mit MySQL Workbench gemacht? Sieht schickt aus!

Grüße
Thomas

[chunky]

Die Tabelle FAVORITEN und MEMBER_HAS_FAVORITEN sind meiner Meinung nach unnötig. Vermutlich genügt es MEMBER_FAVORITEN_KINOFILME als Zwischentabelle zu definieren.

Dann ende ich aber mit einem halbem Dutzend Tabellen jeweils für Favoriten, Ratings und Kommentare...

Ich habe mir angeschaut, wie es in Wordpress und Vbulletin gemacht wird.
Das Problem ist eben, das in diesen Skripten nur Posts gibt, die bewertet oder kommentiert werden.

Ist das Datenmodell mit MySQL Workbench gemacht? Sieht schickt aus!

Ja. Das ist ein wirklich gutes Programm und kommt direkt vom Hersteller.

[thomas_w]

Dann ende ich aber mit einem halbem Dutzend Tabellen jeweils für Favoriten, Ratings und Kommentare...

War natürlich nur ein spontaner Vorschlag meinerseits. Die Frage ist trotzdem, ob der Aufwand jetzt kleiner ist, als später mit eventuellen Problemen zu leben.

Versuche doch mal Beispieldaten zu erfassen und überlege Dir mögliche Abfragen bzw. Inserts/Updates. Sind die "einfach" dann kannst Du alles so lassen, wenn es nicht so einfach ist, dann bleibt immer noch die Idee, da Modell zu ändern.

Grüße
Thomas

[Lenki]

Wie wäre es denn, nur eine Zwischentabelle zu erstellen, die einmal aus der Member-ID, dem Entitätstypen (Film, Serien, ...) und der entsprechenden Entitäts-ID besteht?
Könnte man auch so für Kommentare usw. lösen.

[nikosch]

Also ich tendiere zu zwei Zwischentabellen. Eine klare Trennung. Zum Einen hast Du dann das Problem mit dem NULL los, zum Anderen läuft die Abfrage sonst immer auf ein ODER hinaus ".. id = tvserie_id OR id = kinofilm ..".

Eine andere Lösung wäre, Film und Serie zusammenzuschmeissen. Serie erhielte dann vielleicht ein zusätzliches Flag oder einen FK auf eine Erweiterungstabelle. So unterschiedlich sind die beiden Typen ja nicht.

Für Theateraufführungen und Events gilt das sicher nicht mehr. Ich erkenne allerdings auch nicht wirklich den Zusammenhang zwischen diesen Entitäten.

[chunky]

Eine andere Lösung wäre, Film und Serie zusammenzuschmeissen.

Das habe ich jetzt auch gemacht. Gefällt mir zwar nicht 100%, weil so wie bei Wordpress Inhalte von sehr unterschiedlicher Art in einer einzigen Tabelle gespeichert werden und die Tabelle deshalb auch sehr groß wird (Kinofilme/Serien/Events war nur ein Beispiel für die Inhalte in meiner Datenbank). Drei Spalten zu haben, von denen ich nicht genau weiss, welche gefüllt ist, war jedoch zu kompliziert bei den Abfragen.

In der großen zentralen Tabelle, die ich jetzt habe, gibt es Spalten, die nicht immer gefüllt sind.
In der Praxis, was ist besser:
1.) diese Spalten mit NULL füllen
oder
2.) diese Spalten leer lassen?

[nikosch]

1 === 2