Hi,
ich hab da mal ne Frage zur Performance/Design von Tabellen.
verwendetes Datenbanksystem: sqlexpress
Ich hab als Beispiel folgende Tabellen:
Kunde (1) -> (n) Bestellungen (1) -> (n) Lieferungen (1) -> (n) Artikel
Bei 20 Kunden;
5 - 50 Bestellungen pro Kunde
10 - 15.000 Lieferungen pro Bestellung
max. 200.000 Lieferungen
1 - 100 Artikel Lieferung
Wenn ich jetzt eine WebApp habe in der sich Kunden einloggen können, um sich dann ihre zugestellten Artikel anzuschauen, bewertungen hinzufügen und .. noch ganz viel anderes tolles machen können.
Macht es Sinn Artikel eine Spalte KundenID hinzuzufügen?
Also 'FROM artikel where kundenID == x' anstatt mich per joins durch Lieferungen und Bestellungen zu hangeln (bzw. das EF sich hangeln zu lassen); besonders, da jeder Kunde nur seinen Kram sehen soll und ich diesen Filter ja immer setzen muss, wenn ich Artikel aufliste.
Gruß,
Codi
Wenn du sagst, dass jeder Kunde nur seine eigenen Artikel sehen soll, dann musst du das im Prinzip so machen. gäbe es diesen Verweise nicht, würde ja der Kunde nur die Artikel sehen, die er bereits bestellt hat.
Ein neuer Kunde würde also gar keine Artikel sehen.
Richtig.
Man könnte das Beispiel auch so nennen:
Kontinent (1) -> (n) Region (1) -> (n) Land (1) -> (n) Stadt
Ein click auf Europa liefert z.B. Oslo (in Norwegen, in Skandinavien, in Europa) zurück
Ein click auf Antarktis liefert logischerweise nichts (Pinguine zählen unter Windows nicht)
Die Frage ist nun, ob sowas wie
var x = FROM stadt IN context.Stadt WHERE stadt.Land.Region.Kontinent.Name == "Europa"
spührbare Nachteile gegenüber
var x = FROM stadt IN context.Stadt WHERE stadt.Kontinent.Name == "Europa"
hat; bzw. sich das Hinzufügen einer Spalte für die direkte Stadt-Kontinent-Beziehung (Kunde-Artikel-Beziehung) lohnt?
Hier kann Stadt nur einem Kontinent "gehören".
Kann bei dir ein Artikel wirklich nur zu einem Kunden gehören?
Wohl eher nicht, also musst du es anders lösen.