Designfrage

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.

Obwohl dann das Argument wohl immer noch gilt: Dass ich dann auch immer die Profil Tabelle anfassen muss. Obwohl diese isch eigentlich nicht verändert.

Hier würde dann wohl doch auch die dritte Tabelle einen Sinn machen.

Wie ich das aber mit dem Constraint im EntityFramework von .Net hinbekomme weiß ich immer noch nicht

asc

y-vonne schrieb:

Obwohl dann das Argument wohl immer noch gilt: Dass ich dann auch immer die Profil Tabelle anfassen muss. Obwohl diese isch eigentlich nicht verändert.

Wenn du dir selbst Argumente für die dritte Tabelle gibst, dann brauchst du doch auch nicht zu fragen ;).

y-vonne schrieb:

Wie ich das aber mit dem Constraint im EntityFramework von .Net hinbekomme weiß ich immer noch nicht

Sag bitte zum EntityFramework immer noch die Version (und ggf. den Ansatz an) da, soviel ich mich erinnere, du aus irgendwelchen Gründen doch kein aktuelles .Net verwendest. Je nach Ansatz ist es ohnehin kein Problem (z.B. Wenn es aus dem DB-Model generiert wird). Unter Umständen lässt sich aber in die DB-Generierung (bei einem anderen Ansatz) eingreifen und z.B. noch die Constraint über ein SQL-Befehl nachtragen.

asc schrieb:

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

Bitte teile mir doch mit, wo genau in meinen Erklärungen (zu denen NICHT die trollcharakteristischen, aber vom Inhalt jedoch klar abgrenzbaren LOL-Phrasen gehören!) eine unverständliche Erklärung zu finden ist.

Wenn du dir selbst Argumente für die dritte Tabelle gibst, dann brauchst du doch auch nicht zu fragen

Das Argument ist mir erst nachdem du die Antwort gegeben hast wieder eingefallen.

Sag bitte zum EntityFramework immer noch die Version

Verwende die .Net Version 3.5 und bin somit auf das Entity Framework 1.0 festgelegt.

(und ggf. den Ansatz an)

Modell zuerst. Also ich generiere alles aus dem Designer von Visual Studio.

asc

Schau mal ob das folgende Vorgehen schon im EF 1.0 klappt:
http://www.develop-one.net/blog/2011/06/29/EntityFrameworkModelFirstOnetoOneRelationship.aspx

(Es geht hier ja im wesentlichen um Foreign Key-Constraints).

Ja das geht. Klar. Das mache ich ja auch die ganze Zeit.

Aber wie löst das mein Problem. Verstehe da wohl noch was nicht ganz.

Ich habe nun eine dritte bzw. vierte Tabelle mit dem Namen "ActivRecipe" gemacht. Mit welcher Tabelle verbinde ich diese nun?

Tabelle
1. Profil
2. Rezept
3. ProfilRezept

so dass ich hier nun nur ein jeweils 1 Profil mit einem Rezept anlegen kann. Das aber auch in der Liste ProfileRecipe vorhanden ist.

asc

y-vonne schrieb:

so dass ich hier nun nur ein jeweils 1 Profil mit einem Rezept anlegen kann. Das aber auch in der Liste ProfileRecipe vorhanden ist.

Schau doch einfach mal nach auf welche Tabellen du für deinen Anwendungsfall verweisen musst. Wenn ich dies Richtig verstehe ist dies einmal das Profil, und zum anderen das Profilrezept (Da es ja in diesen enthalten sein muss).

Also sind 2 Foreignkeys sinnvoll: einmal zum Profil, und einmal zum Profilrezept. Zum anderen kann der erstere Foreignkey auch gleichzeitig als Primärschlüssel verwendet werden, da ja nur ein Eintrag je Profil zulässig sein soll.

Schau doch einfach mal nach auf welche Tabellen du für deinen Anwendungsfall verweisen musst

?
Na toll. Das war ja die Frage. Wenn ich einfach nachschauen müsste hätte ich nicht gefragt.

Aber so einfach wie du das sagst geht das nicht. Hast du schon mal was mit dem EF gemacht.

Also

Habe nun folgende Tabellen

Profile Key: ProfileID

Recipe Key: RecipeName

ProfileRecipe Key: Profile_ID -> Bezug zu Profile Key ID
Recipe_Name -> Bezug zu Recipe Key Name

ActiveRecipe Key Profile_ID -> bezug zu Profile Key ID
Recipe_Name ist nicht key. Profile_ID ist eindeutig.

Also die Frage. Worauf hat nun ActiveRecipe noch eine Beziehung und wie?
kann mit Recipe_Name keine Beziehung zu Tabelle "ProfileRecipe" Key "Name" machen da dies kein Schlüssel ist. Desweiteren wenn ich einen Bezug zu ProfileRecipe und zu Profile mache, haben ich einen doppelten Bezug zu ProfileID.

asc

y-vonne schrieb:

Aber so einfach wie du das sagst geht das nicht. Hast du schon mal was mit dem EF gemacht.

Ich habe bereits mit EF gearbeitet, aber weder mit Model First, noch mit EF 1.0 (Vorwiegend 4.3.1 und Code First).

Willst du wirklich einen String als Schlüssel verwenden? Ich hätte hier die Id vom ProfilRezept eingetragen, falls noch nicht vorhanden würde ich schauen ob man hier noch ein Identity-Feld eintragen kann.

ODER: Verwende den Primärschlüssel vom Rezept, und stelle über die Programmlogik sicher, das dies ein ProfilRezept ist.