Designfrage

Hallo zusammen.

In meiner Datenbanken habe ich zwei Tabellen. Nehmen wir mal ein Beispiel.

Student und Studienfach. Hier habe ich nun eine n zu n Beziehung. Und habe dazu eine Zwischentabelle: StudentStudienfach. Jetzt würde ich mir gerne noch in einer Spalte merken wär der beste Student im jeweiligen Studienfach war.

Jetzt habe ich zwei Möglichkeiten: Entweder habe ich in der Zwischentabelle eine Spalte mit bool bester true/false. Oder ich merke mir in Studienfach eine Spalte, bester Student, den Schlüssel von Student.

Welches ist die schönere / bessere Lösung?

In beiden gibt es einen Nachteil. Mit der bool Variante kann man mehrere Studenten in einem Studienfach auf true setzen. Was nicht vorkommen darf.

In der anderen Lösung kann ich aber einen Studenten als besten setzten der gar nicht dieses Studienfach besucht.

(Bitte nicht als Lösung sagen ich kann mir auch die Noten merken und daraus dann den besten ermitteln, es ist hier nur ein Beispiel. Sagen wir einfach Walddorf Uni es gibt keine Noten und nur einen besten )

Nimm die 3. Lösung:

Neue Tabelle StudentStudienfachBester. In der verknüpfst du einfach einen Datensatz aus StudentStudienfach mit deiner boolschen Spalte. Das Studienfach darf nur einmal in der Tabelle StudentStudienfachBester vorkommen.

Ok. Habs aber nur halbwegs verstanden. Für was brauch ich dann noch die boolsche Spalte?

Also doch keine so gute Lösung.

Irgendjemand noch einen verständlichen Vorschlag?

Dritte Tabelle

Studienfachbester mit Referenz auf Studienfach und Referenz auf Student.
Warum sollte man die Info an den JOIN Table hängen?

LOL Alter! Wenn ich sowas lese, lolt es mich regelrecht weg. Da roflt es mir frei die Fußnägel weg.

Also nur raus mit den Vorschlägen LOLAlter.

Das oben war mein Vorschlag.

Mach eine dritte Tabelle Studiengangsbester. Dort eine Referenz auf Studiengang und eine Referenz auf Student, also den besten des jeweiligen Studiengangs.

hustbaer

CREATE TABLE das_kann_doch_nicht_so_schwer_zu_verstehen_sein
(
    INT Studienfach_ID NOT NULL PRIMARY KEY,
    INT Student_ID NOT NULL,

    CONSTRAINT der_muss_das_auch_studieren
        FOREIGN KEY(Studienfach_ID, Student_ID)
        REFERENCES StudentStudienfach(Studienfach_ID, Student_ID)
)

Hm ja genau so hatte ich das auch gemeint. Ziemlich doof wenn man erst nach 2 Tagen wieder in den Thread schaut

Bitte was LOLAlter. Komm mal zurück zur deutschen Sprache.

Ich dachte bei einer dritten Tabelle lolt es dich regelrecht weg. Oder auf was hast du das bezogen.

@hustbear. Wenn ich das mit einem Constraint machen könnte, dann könnte ich ja genauso in Studienfach hinterlegen wer der beste ist. Dazu bräuchte ich ja keine 3 Tabelle.

Da ich aber das EntityFramwork von .Net verwende kann ich keine Constraints anlegen.

Keine Antworten mehr?

Nein, wenn du die Info an den Join-Table hängst, dann und nur dann lolt es mich regelrecht von den Socken.

An die Join-Table würde ich nur Daten hägen, wenn du für JEDE Relation Informationen hinterlegen willst (etwa den Notenschnitt für jeden Studenten, in jedem Kursfach).
Die Info "Jahrgangsbester Ja/Nein" impliziert aber m.E. eine Redundanz, denn hängst du sie in den Join-Table, so würdest du sie für eine Relationsinstanz auf True setzen, für alle anderen auf False. Da es nur einen Jahrgangsbesten geben kann, hast du aber mit dem "True"-Fall schon eine Aussage für alle anderen gemacht.

Daher: Lege für die Zuordnung Kurs <-> Jahrgangsbester eine dritte Tabelle an, wie schon vorgeschlagen.

Alternativ: Lege beim JOIN-Table die Info zum Notenschnitt für jeden ab. Der Jahrgangsbeste muss dann garnicht gespeichert werden sondern kann implizit über ein Query gefunden werden (Order By Notenschnitt DESC TOP 1)

Hast du das jetzt gerallt?

hustbaer

y-vonne schrieb:

@hustbear. Wenn ich das mit einem Constraint machen könnte, dann könnte ich ja genauso in Studienfach hinterlegen wer der beste ist. Dazu bräuchte ich ja keine 3 Tabelle.

Ja, richtig. Alleine aus der Tatsache dass Studienfach_ID der Primary Key der Tabelle ist sieht man schon dass man das eigentlich auch als Feld in der Studienfach Tabelle machen könnte.

Ich wollte auch nur demonstrieren wie der Vorschlag von x++ bzw. LOLAlter gemeint war, da du den offensichtlich nicht verstanden hast.

Da ich aber das EntityFramwork von .Net verwende kann ich keine Constraints anlegen.

Soso.
Geht das denn mit dem Entity Framework nicht? Würde mich sehr wundern.
Andrerseits hab' ich mit dem Entity Framework auch noch nix gemacht.

LOL Alter schrieb:

Alternativ: Lege beim JOIN-Table die Info zum Notenschnitt für jeden ab. Der Jahrgangsbeste muss dann garnicht gespeichert werden sondern kann implizit über ein Query gefunden werden (Order By Notenschnitt DESC TOP 1)

Wie gesagt geht nicht. Siehe erster Post.

@hustbaer:
Ok. Denke LOL Alter hat das nur etwas komisch erklärt. Meiner Meinung macht es keinen Sinn dazu eine dritte Tabelle zu verwenden.

hustbaer schrieb:

Geht das denn mit dem Entity Framework nicht? Würde mich sehr wundern.

Nein geht nicht:
http://blogs.msdn.com/b/efdesign/archive/2011/03/09/unique-constraints-in-the-entity-framework.aspx

Und da ich keinen Unique Constraint verwenden kann, hat es für mich mehr Sinn gemacht das ganze an die Jointabelle zu hängen.

Besser ich habe 2 "Beste" im Studienfach als einen Besten der gar nicht das Studienfach besucht.

Oh Moment.

Habe da wohl irgendwie Constraints mit einem Unique Constrain verwechselt. Da muss ich wohl nochmals genauer schauen.

y-vonne schrieb:

Meiner Meinung macht es keinen Sinn dazu eine dritte Tabelle zu verwenden.

Kannst du diese Meinung kurz erläutern? Würde mich interessieren, was dagegen spricht.

Für was brauch ich noch eine Tabelle in der nur die eine Information steht. Das ist doch oversized.

Was spricht den dagegen wenn ich in Studienfach eine Spalte habe steht in der der beste Student steht?

zwutz

y-vonne schrieb:

Was spricht den dagegen wenn ich in Studienfach eine Spalte habe steht in der der beste Student steht?

Flexibilität.

Studienfächer sind fix, die ändern sich recht selten. Der beste Student ändert sich aber idR jährlich.

Was ist, wenn du die besten Studenten des Faches der letzten n Jahre haben willst? Oder die besten drei? Oder den Studenten, der während seiner Laufzeit am häufigsten Bester eines Faches war. Alles nur mit einer zusätzlichen Tabelle lösbar, in der du dann z.B. auch das Jahr als weiteres Schlüsselelement mit aufnehmen kannst

Ich weis jetzt nicht ob das auch als Argument für die 3-Tabellen Version zählt. Aber der Vorteil ist meiner Meinung nach auch, dass du die Basisdaten (Studienfach und Student) nicht ändern musst. Du Gewinnst neue Informationen in dem du diese Tabellen einfach nur Verknüpfst und dadurch anders interpretierst (vielleicht könnte man hier je nach Design auch eine View verwenden). Außerdem bräuchtest du eine Programmlogik, die die boolsche Spalte "Studienfachbester" pflegt. Und wenn du in der 2-Spalten Version für jede Info immer eine neue Spalte einfügst (Studienfachbester, Studienfachschlechtester, Jahrgangsbester usw...) immer eine neue boolsche Spalte anfügst, dann hast du ganz schnell einen undurchsichtigen Wildwuchs.

Gerade der Wildwuchs und die zusätzliche Programmlogik kosten später in der Wartungsphase mehr Geld.

Jetzt greife ich das Thema doch nochmal auf. Vieleicht habe ich zu viel abstrahiert.

Würde gerne mein Problem nochmals erleutern. Und dabei näher an meinem konkretten Fall bleiben.

Es ist so ich habe eine Liste mit Profilen. Und eine Liste mit Rezepten.
Hier besteht nun eine n zu n Beziehung. Also ein Profil kann mehrere Rezepte haben und ein Rezept kann zu mehreren Profilen gehören.

Nun würde ich mir gerne einfach noch merken welches das aktive Rezept eines Profils ist.

Und das ist jetzt die Frage wo das hingehört. Es kann also nur ein aktives Rezept geben. Und nicht irgendwie die letzten 3 oder sonst was ausgedachtes.

Seit ihr dann immer noch der Meinung das ich dann eine dritte Tabelle benötige?

asc

y-vonne schrieb:

Nun würde ich mir gerne einfach noch merken welches das aktive Rezept eines Profils ist.

Ich würde in diesem Fall wohl einfach eine RezeptId in die Profiltabelle packen.

P.S: @LOLAlter: Versuch es mal mit Deutsch, das können mehr Leute verstehen.