Relationen in dritter Tabelle

[hiok]

Guten Tag,

ich frage mich, wie man dieses Problem am besten angeht. Ich habe folgende Tabellen:

benutzer | gruppe
id       | id
name     | name

Nun möchte ich eine dritte Tabelle erstellen, die die Freundschaften dieser Gruppen und Benutzer darstellt. Gruppen können mit anderen Gruppen befreundet sein, Benutzer mit Benutzern und Benutzer mit Gruppen.

Nun überlappen sich jedoch die id aus "benutzer" mit der id aus "gruppe". Wie stelle ich dies nun also mit dieser Tabelle an:

freundschaften
partner1
partner2

P.S.: Sollte man zu der Tabelle "freundschaften" auch ein id-Feld hinzufügen?

[tkausl]

Entweder nutzt du in der Freundschaften-Tabelle ein flag, ob es eine Gruppen- oder Benutzerfreundschaft ist oder du nutzt für beides eine eigene Tabelle.

ID's brauchst du nicht, ist glaube ich auch unüblich diese in n:n zwischentabellen zu nutzen.

[hiok]

freundschaften_gruppe_benutzer | freundschaften_gruppe_gruppe | freundschaften_benutzer_benutzer 
gruppe                         | gruppe1                      | benutzer1                 
benutzer                       | gruppe2                      | benutzer2

So in etwa? Oder wäre es besser eine flag 0 - 2 zu setzen?

[akretschmer]

Entweder nutzt du in der Freundschaften-Tabelle ein flag, ob es eine Gruppen- oder Benutzerfreundschaft ist oder du nutzt für beides eine eigene Tabelle.
.

Sauberer wäre, die DB das prüfen zu lassen. Dafür wurden Check-Constraints erfunden, vor langer Zeit. Mal so aus dem Daumen geschüttelt:

test=# create table benutzer (id int primary key, name text);                                                                          CREATE TABLE
test=*# create table gruppe (id int primary key, name text);                                                                           CREATE TABLE
test=*# create table freunde (f1 int references benutzer, f2 int references gruppe, f3 int references benutzer, f4 int references gruppe, check (((f1 is null and f2 is not null) or (f1 is not null and f2 is null)) and ((f3 is null and f4 is not null) or (f3 is not null and f4 is null))));
CREATE TABLE

Mit einem Flag kannst Du nicht arbeiten, da könntest Du keine RI mehr verwenden. Und 2 Tabellen ist auch bäh. Würde auch nicht reichen, du brächtest mehr.

[hiok]

Soweit ich aus Google nun erfahren habe existieren für MySQL keine Check-Constraints. Richtig?

[akretschmer]

Soweit ich aus Google nun erfahren habe existieren für MySQL keine Check-Constraints. Richtig?

MySQL kennt die Syntax, setzt die Constraints aber nicht durch. Du hast MySQL? Warum, gehst Du immer auf den Müll und nimmst das erst-beste mit zum essen?

[hiok]

MySQL kennt die Syntax, setzt die Constraints aber nicht durch. Du hast MySQL? Warum, gehst Du immer auf den Müll und nimmst das erst-beste mit zum essen?

Ich habe noch nie mit PostgreSQL gearbeitet. Ist der Umstieg schwer? Was ist zu beachten? Habe mir schon öfters überlegt von MySQL weg zu gehen, jedoch wollte ich mir bisher nie neues Know-How in dieser Gegend zulegen und mich auf andere Bereiche fokusieren.

[akretschmer]

Ich habe noch nie mit PostgreSQL gearbeitet. Ist der Umstieg schwer? Was ist zu beachten?

Unter PG funktionieren die Dinge halt (siehe Constraints), und es kann mehr. Viel mehr. Es ist pingelig, was konsistente Daten anbelangt. Aber das sollte man bei einer DB eher als Vorteil sehen. Probier es aus.[/QUOTE]

[daten-k]

Dafür ist die Konsole Dreck

[akretschmer]

Dafür ist die Konsole Dreck

Kannst Du das näher erklären?

[daten-k]

Klar: Wenn ich in der PG-Konsole mehrere Abfragen gegen die DB mache, dann sind die letzten Ergebnisse stets nicht mehr sichtbar (Linux), das ist bei MySQL geschickter gelöst. Dafür skaliert PG deutlich besser...

[akretschmer]

Klar: Wenn ich in der PG-Konsole mehrere Abfragen gegen die DB mache, dann sind die letzten Ergebnisse stets nicht mehr sichtbar (Linux),

Dann machst Du was falsch.