ich empfehle immer, Datenmodellierung ohne Datenbank zu erlernen. Mit Db - auch wenns EF-getrieben ist - holt man sich nur lauter zusätzliche Komplexität ins Projekt, die man viel besser in einer eigenen Baustelle behandeln sollte.
Also ohne Db gehts so: codeproject.com/Articles/10309…l-Datamodel-for-Beginners

Wie dem auch sei.
Bei deim Datenmodell verstehe ich schon garnet, was du eiglich modellieren willst.
Die Kategorien - sind das Speise-Kategorien (Mehlspeisen, Steak, Kartoffelgerichte, Salat) oder Restaurant-Kategorien (Bürgelich, Italiener, Snob_SuperTeuer, Mensa) ?

Jo, weiter brauch ich garnet gehen, an deine Antwort schließen sich sicherlich weitere Fragen an.

Ich gebe da ErfinderDesRades recht. Ein Datenmodell zu verstehen ist grunsätzlich wichtig.

Dennoch bin ich der Meinung, falls du EF 6 mit CodeFirst Ansatz betreibst ist in diesem Fall nicht notwendig ZU tief in die Materie einzutauchen.

Wenn du die Kategorie in der Speise hinterlegst passt das schon.
Du hast ein Restaurant. Ein Restaurant hat X Speisen eine Speise aber nur 1 Restaurant.
Eine Speise hat eine Kategorie aber eine Kategorie kann X Speisen zugeordnet werden.

Bilde das so in Klassen mit ICollections ab und EF wird dir die richtigen Tabellen erzeugen.
Du kannst aber auch Kategories anlegen für welche es (noch) keine Speisen gibt indem du das Feld als Nullable definierst.

Du kannst dann ganz leicht mit _context.Categories.ToList alle Kategories abfragen.

Grüße
Sascha

Eine Speise kann in mehreren Restaurants (zu unterschiedlichen Preisen) vorhanden sein.

Restaurant A Pizza Salami 8,00€
Restaurant B Pizza Salami 7,80€
Restaurant C Pizza Salami 8,10€

Ansonsten muss man die Salami Pizza jedes mal neu anlegen. Evtl. Sollte man eher an einen "Speisen-Stamm" denken.

Du legst jede Speise an, egal wo.man die kaufen kann. Dann kann man jeder Speise X Restaurants zuordnen und angeben was sie dort kosten.

mrMo schrieb:

Salami Pizza jedes mal neu anlege

Ich würe es so machen. Flexibler, so kann in verschiedenen Restaurants die Pizza einen anderen Belag oder Rezept haben sowie unterschiedliche Allergene.
Ne Pizza Diavolo ist nicht überall gleich.

Grüße

KingLM97 schrieb:

Das sieht mir irgendwie richtiger und besser aus, oder?

Zumindest kann man (ich zumindest) nun sofort dein Datenmodell verstehen, und Knackpunkte ansprechen.

Bei dir hat eine Speise viele Kategorien, und eine Kategorie hat viele Speisen - eine m:n-Relation.
Bei dir soll es also Speisen geben können, die sowohl Brötchen sind als auch Suppe?

Ein Restaurant hat viele Kategorien und eine Kategorie hat viele Restaurants - eine m:n-Relation.
Bei dir soll es also Restaurants geben können, die sowohl ein Imbiss sind als auch FeinschmeckerTeuer?

Und die Spitze ist, dass beide Entitäten - Restaurant und Speise - mit derselben Kategorien-Entität verknüpft sind.
So sind bei dir Speisen der Kategorie Imbiss möglich, aber auch Restaurants der Kategorie Brötchen.

Hmm - äh - unkonventionell...

---

Wie im Link erläutert: Zum Datenmodellieren muss man weniger an Code oder sonstwas schwieriges denken, sondern über die Realität, und möglichst konkret über die Realität denken.
Also in meiner Welt hat eine Speise eine Kategorie: Entweder es ist ein Brötchen, oder es ist Suppe - beides geht nicht.
Ebenso die Restaurants: Entweder Italiener oder Grieche.

(Prinzipiell gibt es durchaus Problemstellungen, die eine multiple Kategorisierung nahelegen - etwa eine Fotosammlung, da kann ein Foto sowohl Landschafts-Aufnahme als auch Porträt sein.
Aber ob vergleichbares bei dir zutrifft ziehe ich in Zweifel.)

@ErfinderDesRades

Du gehst nicht so oft Essen?

Ein Restaurant kann sowohl griechisch, wie auch gut Bürgerlich anbieten. Es gibt Imbisse die sind dennoch Snob-teuer.
Eine Suppe kann sowohl Vorspeise sein, wie auch Hauptgericht, Vorspeise und vegan ....

ja, und ja
ja, ich bin nicht der Essen-Geher

Und ja, muss @KingLM97 sich überlegen, ob er das so modellieren will.
Und das Problem mit dem Restaurant der Kategorie Brötchen und der Speise der Kategorie Italiener bleibt nachwievor zu lösen.

KingLM97 schrieb:

Meinem Verständnis nach ... jedes Restaurant mehrere Kategorien.

Wie wolle.
Deine Entscheidung, nu lebe mit den Konsequenzen...

---

Bleibt noch das 2. von mir genannte Problem.
Nenn bitte mal ein paar beispiele für Speise-Kategorien - also was du dir vorstellst, was in Kategorie-Tabelle an Datensätzen eingetragen sein könnte - Name reicht.

Fein, und so wie du dein Datenmodell gebaut hast, kannst du diese Kategorien jetzt auch den Restaurants zuordnen:
Also bei dir gibts nun auch Restaurants der Kategorie "belegtes Brötchen".

Ist das so beabsichtigt?

ganz einfach: Eine Speise-Kategorie ist was anderes als eine Restaurant-Kategorie.
Daher müssens 2 getrennte Tabellen sein.

---

Nächster Punkt: Ich hätte erwartet, dass eine Zuordnung möglich ist zwischen Speisen und Restaurants.
Also dass ich sehen kann: welche Speise bekomme ich in welchem Restaurant?

Oder hast du das mit Absicht nicht vorgesehen?

ah - ok, dann habich zu deim Datenmodell keine weiteren Anmerkungen

Da steckt trotzdem ein Denkfehler drin. Denn die Speisen sind an Kategorien gebunden. Das Restaurant bietet aber verschiedene Speisen an! Also kann das Restaurant nicht direkt an "Nudelgerichte" gebunden werden. Sondern die Speise "Nudel ala Mama" ist an die Kategorie "Nudelgerichte", "Tomatengericht", "Vegan" gebunden. Und ein Restaurant bietet diese Speise an oder nicht.

Der zweite Entwurf war richtig. Nur muss RestaurantKategorie verworfen werden. Dafür muss die Kreuztabelle SpeisenRestaurant erstellt werden. Damit lassen sich dann über die Speisen einer Kategorie die Restaurants finden oder über die Restaurants die angebotenen Speisen einer Kategorie.

Und selbst hier habe ich noch einen Denkfehler, weil "Vegan" auf Restaurant 1 zutreffen kann aber nicht auf Restaurant 2.