SQL SQL Datenmodell

derocco · 12. August 2016

Irgendwie komme ich nicht ganz klar mit meinem Datenmodell, bzw denke ich es gibt noch einen besseren weg das zu designen...

Ansatz:
- Es gibt einen Kunden, der hat verschiedene Filialen (10)
- Jede Filiale hat zugelassen Sprachen (ava_lang) (1...n) (aktuell 2 Sprachen) (Die können sich ggf ändern, das heisst man will einer Filiale ev. plötzlich mehr sprachen geben oder eine wegnehmen)
- es gibt 1800 Products mit Description in aktuell je 2 Sprachen (Deu / Eng -> Später soll das euch noch FRA / ITA sein)

Ich will anfragen: Alle Produkte in allen verfügbaren Sprachen für einen Filiale.

Code:

SELECT DISTINCT  p.product_name, p.long_description, language
FROM branches b 
join ava_lang av on av.branch_id = b.branch_id
join branch_product bp on bp.branch_id = b.branch_id
join products p on p.product_id = bp.product_id
where b.branch_name = 'SG';
--where b.branch_name = 'ZH';

Das klappt soweit eigentlich.

Trotzdem bin ich nicht sicher ob das der schlauste Weg ist...

Wie würdet ihr das lösen?
Eventuell noch product aufteilen in einen Teil der Language Abhängig ist und einen immer gilt? (Preis, Kategorie etc)

AgiOli · 12. August 2016

Was hier noch fehlt ist die Festlegung des Produktes auf die Sprache der Filiale.
Also statt

Code:

join products p on p.product_id = bp.product_id

sollte es heissen

Code:

join products p on p.product_id = bp.product_id and p.language = av.language_id

Was gefällt Dir an dem Weg nicht? Ich würde es genauso verknüpfen.

Die Überlegung, das Produkt aufzuteilen in einen festen und einen sprachabhängigen Teil würde ich mit einbauen.

Im Diagramm fehlen im Prinzip noch die 1:1 Links zwischen products.Language und Languages.Language_id sowie zwischen branches.std_language und Languages.language_id

derocco · 12. August 2016

Danke für den hint,

Ja wegen dem Aufteilen dachte ich eben auch. Das soll dann ja auch noch maintainable bleiben.
Das heisst es wird via Excel Tabelle mir angeliefert und ich würde das dann n die DB pumpen.
Wenn es nun updates an artikeln gibt, zb preis, dann könnte man das schneller updaten.

Aber vom Tabellenkonzept her sonst würdeest du das so belassen?

fhtagn · 14. August 2016

Ich habe mir das Diagramm angeschaut:
- brauchen die Verknüpfungstabellen branch_product und ava_lang wirklich eigene Primärschlüssel?
- Tabellennamen von Entitäten sind manchmal Mehrzahl, manchmal nicht
- Primärschlüssel sind manchmal id und manchmal Entität_id

Ansonsten sind die Verknüpfungstabellen genau richtig. Viele Filialen haben viele Produkte. Viele Filialen unterstützen mehrere Sprachen. Was wie gesagt noch fehlt: Produkte in mehreren Sprachen.

derocco · 15. August 2016

Danke,

die Products haben ja ein language_id drinnen.

Code:

SELECT DISTINCT  p.product_name, p.long_description, language
    FROM branches b 
    join ava_lang av on av.branch_id = b.branch_id
    join branch_product bp on bp.branch_id = b.branch_id
    join products p on p.product_id = bp.product_id and p.language = av.language_id
    where b.branch_name = 'SG';
    --where b.branch_name = 'ZH';

Wenn ich das so wie AgiOli anspricht erweitere, dann kriege ich doch:

Alle Produkte für einen Filiale, die für derne spezifizierte Languages (Ava_Lang) zur verfügung stehen.

AgiOli · 16. August 2016

Ich muss fhtagn in Recht geben. Falsch sind die Punkte nicht - ein bisschen unschön halt.

Was mir noch aufgefallen ist, ist in der Tabelle Products gibt es die Spalten Language und Language_id das ist etwas verwirrend und der Unterschied ist mir nicht ganz klar.

derocco · 16. August 2016

Das sit auch ein Fehler Language sollte da nicht stehen.

derocco · 22. August 2016

Ich habe mein Datenmodell nun mal noch erweitert um eine tabelle SUITABLE.
Zu jedem Product passen 0...5 Produkte (Vorschläge für den Kunden was er dazu kaufen kann)

Wenn ich das so mache, dass ich da in der Suitable tablle wieder die Keys der Product tabelle speichere, dann muss ich ja bei einer Abfrage 5 mal auf die Product tabelle joinen...

Code:

        join suitable suit on suit.suitable_id = p.suitable_id
	join products p1 on p1.product_id = suit.product_id_1
	join products p2 on p2.product_id = suit.product_id_2
	join products p3 on p3.product_id = suit.product_id_3
	join products p4 on p4.product_id = suit.product_id_4
	join products p5 on p5.product_id = suit.product_id_5

Das mag wohl noch gehen solange die Tabellen fast leer sind....

Wie löst man sowas eleganter?

AgiOli · 22. August 2016

Dein Vorgehen hat, ausser dass es nicht sehr elegant ist, einen weiteren eklatanten Nachteil:
Du hast jetzt fix 5 mögliche Vorschläge eingebaut - was machst Du, wenn es plötzlich 6 Vorschläge sein sollen?
Ich würde die Suitable-Tabelle mit den folgenden Spalten aufbauen:

ProductId
OrderId
SuitableProductId

Die ProductId verweißt auf das Produkt, die SuitableProductId auf den jeweiligen Vorschlag und die Order sagt aus, welchen Stellenwert / Position der Vorschlag hat.
Den Primärschlüssel auf ProductId und OrderId und Du kannst noch einen CheckConstraint auf die OrderId setzen, so dass diese zwischen 1 und 5 liegen muss - so hättest Du wieder Deine Beschränkung auf maximal 5 Vorschläge realisiert.

Suche

SQL SQL Datenmodell

derocco

Lt. Junior Grade

AgiOli

Cadet 4th Year

derocco

Lt. Junior Grade

fhtagn

Ensign

derocco

Lt. Junior Grade

AgiOli

Cadet 4th Year

derocco

Lt. Junior Grade

derocco

Lt. Junior Grade

AgiOli

Cadet 4th Year