Designfrage

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.

Willst du wirklich einen String als Schlüssel verwenden?

Jo muss sein.

Kannst du mir sagen wie man dann das im Management Studio macht. Also den Constraint. Dann kann ich mal aus der Datenbank mein Model generieren. Dann sehe ich wie das dort sein muss.

kann mit Recipe_Name keine Beziehung zu Tabelle "ProfileRecipe" Key "Name" machen da dies kein Schlüssel ist

Denke das ist das Hauptproblem. Habe nun zuerst mal die Tabelle in der Datenbank erstellt. Und dann daraus das Modell aktualisiert und bekomm dann folgende Fehlermeldung:

Beziehung 'FK_ActiveRecipes_ProfileRecipes' verwendet das Set der Fremdschlüssel '{Profile_ID, Recipe_Name}', die teilweise im Primärschlüsselset
 '{Profile_ID}' von Tabelle 'ActiveRecipes' enthalten sind. Das Fremdschlüsselset muss entweder vollständig im Primärschlüsselset enthalten 
oder vollständig nicht enthalten sein, damit eine Zuordnung zu einem Modell möglich ist.

Es wird dann wohl nur so gehen wie du asc schreibst.

Entweder noch eine ID für ProfilRezept einfügen. Wofür es andere gründe gibt warum ich das nicht möchte.

Darum nehme ich halt dann den zweiten Lösungsvorschlag.

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

Danke mal an alle!