Performance/Tabellen-Design: HilfsID-Spalte vs. mehreren Joins?

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.