Simple Datenbankdesign-Frage - Beste Lösung?
Hallo ,
ich hätte mal für eine simple Datenbankanforderung an euch die Frage was der beste Lösungsansatz ist.
"Problem" ist folgendes: es soll eine Kundentabelle geben , eine Tabelle für Produkte und eine Tabelle für die Preise der Produkte. Die Preise für die Produkte sollen individuell für jeden Kunden adminstrierbar sein (deswegen können die Preise auch nicht zusammen mit den Produkten in eine Tabelle) und die Anzahl der Produkte soll variabel sein (es können ständig neue Produkte hinzu kommen bzw. gelöscht werden).
Wie sieht hier das "beste" Datenbankdesign aus?
So: ?
Tabelle "Preisliste":
ProduktID
KundenID
Preis
Wenn ja , wie fragt man so was z.B. in Linq am besten ab? Wie müsste das Mapping in DLINQ aussehen?
Und eine ganz wichtige Frage: wie binde ich so etwas an GridView-Controls (z.B. um eine Übersicht aller Preise für jeden Kunden anzuzeigen?)
Gruß und danke schon mal
verwendetes Datenbanksystem: MS SQL Server 2005
Hallo amorph,
das DB-Design würde ich so gestalten, wie Du vorgeschlagen hast:
1 Tabelle Kunden und 1 Tabelle Produkte. Des weiteren dann eine Preistabelle mit KundenID, ProduktID und Preis.
Wichtig ist, dass Du einen intelligenten Index darauf setzt. Ich würde hier einen Index auf die Kombination KundenID und ProduktID legen, ebenfalls würde ich einen Index auf die KundenID legen, damit schnell alle Preise zu einem Kunden gefunden werden können.
Über Linq kann ich nichts sagen.
Grüße
Norman-Timo
Edit Sinn durch vergessen einer Spalteninformation entstellt
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Hallo norman_timo,
du hast geschrieben das du einen Index auf die Kombination legen würdest
Ich würde hier einen Index auf die Kombination KundenID und ProduktID legen
Darf ich fragen, wie du das meinst?
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
Hallo Norman-Timo,
vielen Dank schon mal für deine Infos. Wenn du zu Linq nichts sagen kannst ... hättest du vielleicht eine Idee wie das mit ASO.NET aussehen würde. Vor allem wie man so etwas an Datenausgabecontrols (Gridview) bindet würde mich sehr interessieren.
@LastGentleman: ich glaube Norman-Timo meinte damit einen Primary-Key auf die Kombination aus KundenID und ProduktID zu legen und über diese Kombination einen Index zu erstellen.
Gruß
Hallo zusammen,
ein Primärschlüssel zeichnet aus, dass immer ein Index und vor allem eine Eindeutigkeit vorgegeben wird. Also wäre das tatsächlich hier eine Herangehensweise, da zu jedem Kunde+Produkt nur ein Preis existieren darf (sollte).
Darüber hinaus kann man aber noch zusätzlich viele Indizes legen. Das Ganze funktioniert dann so, wenn man in einer WHERE-Klausel dementsprechend diese Spalten einschränkt, dann kann die DB nach einem Index schauen (Das ist ähnlich der Dictionaries, nur dass man einen kombinierten Key angeben kann).
Aber Vorsicht, nicht alles eignet sich für einen Index! Eine Spalte mit Text wird sich im seltensten Falle als Index eignen, besonders weil Groß-/Kleinschreibung und auch die Reihenfolge (kommt ß vor A oder a?) hier relevant sind.
hättest du vielleicht eine Idee wie das mit ASO.NET aussehen würde.
Das hängt nun etwas von der Datenbank ab. Ich würde normalerweise einen DB-Spezifischen .NET Connektor einsetzen, und dann mittels SQL Syntax ein DataSet erzeugen lassen. Falls Daten nur Readonly sind, dann kann man auch Stored Procedures bauen, die dann mittels einem DataAdapter oder ebenfalls über reines SQL-Query abgerufen werden kann.
Das ist Geschmackssache und hier gibt es auch keine Best-Ways. Es gibt sicherlich ein paar No-Gos, diese sind aber relativ klar (z.B. keine String-Zusammensetzung bei SQL Parametern sondern ein SQLParameter verwenden etc...)
Ich hoffe ich konnte Dir etwas helfen?
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Hallo amorph,
evtl ist es in diesem Zusammenhang auch zu empfehlen, ein "Gültig-Ab"-Datum mit aufzunehmen. Zum einen hast du damit die Historie, zum anderen kannst du vorab neue Preise einpflegen (sowas kann ja durchaus ein paar Tage dauern, aber erst ab Stichtag wirksam werden).
Evtl überlegst du dir auch, die Preis selbst in eigenen Preisliste zu speichern, also:
- preislisteID
- produktID
- Preis
Und dann dem Kunden eine Preisliste zuordnen:
- KundenID
- PreislisteID
- GueltigAb
Das mit der Preisliste hat den Vorteil, das du das auch relativ einfach z.B. um Mengenstaffeln erweitern kannst.
Gruß Thomas
Hallo telebumm ,
danke , das ist eine super Idee!
Könnte mir vielleicht nochmal jemand einen Tipp für ein SQL-Statement geben um diese Preisliste an ein Grid zu binden?
Gruß und danke
Hallo amorph,
Könnte mir vielleicht nochmal jemand einen Tipp für ein SQL-Statement geben um diese Preisliste an ein Grid zu binden?
Man kann nicht direkt mittels SQL Daten an ein Grid binden (außer man bezwichnet Linq als SQL). Je nachdem was für ein Connektor Du einsetzt (im Framework ist z.B. der MSSQL-Server-Connektor enthalten) wirst Du eine Abfrage formulieren müssen, um ein DataSet zu erhalten. Dieses kann dann per DataSource Eigenschaft z.B. an ein DataGridView gebunden werden.
Ein Beispiel wie es mit der MS-Northwind Datenbank aussehen könnte wäre hier zu finden:
MSDN - DataGridView.DataSource Property
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Hallo telebumm,
ist es dann aber nicht aufwändig immer den letzten aktuellen gültige Preis zu ermittlen, bei 150 Artikeln ist das noch nicht so der Aufwand, aber wenn man 200000 Artikel hat und diese wiederum im Schnitt über einen Zeitraum von 5 Jahren 10 Preise haben, dann wird das ganze aufwändig.
Wäre es vielleicht nicht besser diese in eine eigene Tabelle wegzuarchivieren?
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
die Preis selbst in eigenen Preisliste zu speichern
Ob man die Preise in einer Preisliste speichert und diese dann dem Kunden zuordnet oer gleich einen Kunden-Sonder-Preis eingibt hängt von den Anforderungen ab.
Wenn es nur einige Preise gibt kann eine Preisliste sinnvoll sein.
Wenn die Preise aber individuell pro Kunde vergeben werden ist sicher die Variante Kunden-Sonder-Preis sinnvoller.
Bedenke dass Du bei den Preislisten auch pro Kunde eine Preisliste anlegen musst und dann auch wissen musst welche Preisliste welcher Kunde ist.
Gute Warenwirtschaftssysteme bieten deshalb beide Varianten (und noch viele mehr).
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Hallo LastGentleman,
Wäre es vielleicht nicht besser diese in eine eigene Tabelle wegzuarchivieren?
Das ist natürlich auch denkbar. Kommt immer auf das Ziel der Anwenung an. Üblicherweise ist es jedoch so, das die ermittelten Preise sowieso in den Auftrag reinkopiert werden (also bewusst denormalisiert), damit die Stammdaten- und Preisabteilung nicht bestehende (und möglicherweise schon längst abgeschlossene) Aufträge oder Angebote modifiziert.
Oftmals werden ja die Preise im Rahmen von Einkaufsverhandlungen angepasst.
Daraus ergibt sich, das die Preisermittlung einmalig bei Neuerfassung der Position läuft - für die Performance also nicht so entscheidend ist.
Altdaten lassen sich danach archivieren, sobald ich aber doch wieder darauf zugreifen möchte (z.B. Statistiken, die Listenpreise den tatsächlich gewährten gegenüberstellen), werden diese Zugriffe aufwändiger.
Man muss sich also für jede Applikation neu entscheiden.
Gruß Thomas
EDIT: Bernd hat schneller getippt