Hilfe bei Datenbankdesign für Lagerverwaltung
Hallo zusammen,
ich plane eine kleine Lagerverwaltungssoftware für meine Vorratskammer zu entwickeln.
Hierzu benötige ich etwas Hilfe beim Design der Datenbank. Den bisherigen Entwurf meiner Datenbank habe ich als Bild angehängt.
Ich werde MS SQL 2014 Express dafür benutzen.
Kurze Erläuterung zu den Tabellen:
In der Tabelle "Artikel" sollen (wie der Name bereits vermuten lässt) die Artikel an sich eingetragen werden.
Diese werden dann in der Tabelle Artikelgruppe zusammengefasst, wenn Sie den gleichen Typ haben.
Die Artikelgruppen werden dann noch in der Tabelle Warengruppe verknüpft.
Beispiel:
Als Artikel ist angelegt H-Milch von Marke xy und H-Milch von Marke yz, beide Artikel werden der Artikelgruppe H-Milch zugewiesen, damit über die Artikelgruppe H-Milch der gesamte Bestand aller Artikel in der Gruppe abgefragt werden kann.
Die Artikelgruppe H-Milch wird dann noch der Warengruppe "Konserven" hinzugefügt (nur ein Beispiel, ist noch nicht für alle Artikel zuende gedacht 😄)
So weit ist das auch alles kein Problem.
Der Punkt an dem ich etwas scheitere:
Ich möchte zu den Artikeln jeweils ein MHD erfassen.
Eine Option wäre sicherlich, das MHD einfach in den Artikel mit aufzunehmen, allerdings könnte ich dann den EAN nicht mehr als Primärschlüssel verwenden und es würde für jedes MHD des Artikels ein eigener Eintrag in der Datenbank verbleiben.
Deshalb dachte ich man könne es auslagern in eine separate Tabelle, weiß aber nicht genau ob und wie das machbar ist. In dem angehängten Datenbankschema habe ich bereits eine Idee dazu eingefügt.
Meine Überlegung ist, eine separate Tabelle für das MHD zu erstellen, in der tatsächlich nur das Ablaufdatum erfasst wird. Die Tabelle wird dann mit dem MHD-Feld der Artikeltabelle verknüpft. Allerdings wäre es Sinnvoll hier noch eine Menge mit einzubringen, da man ja meist wenn man 5 gleiche Produkte kauft auch verschiedene MHDs hat. Hier bin ich mir aber wieder etwas unsicher wo diese Menge erfasst werden muss.
Ich hoffe mein wirrer Gedankenerguss ist einigermaßen verständlich 😁
Vielen Dank bereits vorab für eure Antworten!
Gruß,
ankou87
Die Datenbank (Typ, Struktur) ist eigentlich einer der letzten Schritte in der Entwicklung.
Deklariere Datenservices als Interface und entsprechende Model-Klassen. Baue darum deine Anwendung. Wenn dann alles steht, dann entscheide dich für eine Datenbank und lege die Struktur fest.
Dein ausgelagertes MHD bringt dir nichts. Ein Artikel zeig auf ein MHD. Mehrere Artikel können auf das selbe MHD zeigen, was aber Unsinn ist denn das MHD kannst du dann auch direkt beim Artikel eintragen. EIN Artikel kann aber nicht auf MEHRERE MHD zeigen, das ist was du willst?
Du musst den Artikel aufteilen. Einmal gibt es die unveränderlichen Stammdaten zum Artikel. Wie heißt er, woher kommt er, welcher EAN Code. Dann gibt es eine Tabelle mit dem Bestand. Ein Eintrag zeigt auf die unveränderlichen Stammdaten und enthält die Anzahl und das MHD.
Damit gibst du einmal an dass du Milch bevorraten willst. Diese Daten bleiben immer bestehen, auch wenn du keine Milch im Haus hast.
In der anderen Tabelle steht dann wie viel Milch du hast und wie lange die haltbar ist. Da kann es dann mehrere Einträge geben, 2 Pack Milch sind noch 3 Tage haltbar und 3 andere noch eine Woche.
Denke darüber nach wie du dein Programm bedienen willst. Dann fällt dir auf dass du nicht für jeden Pack Milch erneut Hersteller und alles sonstige eingeben willst. Du willst nur eingeben dass du soeben Milch gekauft oder verbraucht hast.
(davon abgesehen dass du das für eine private Voratskammer möglicherweise bald nicht mehr nutzen willst - dann ärgere dich nicht darüber 😉
Bleiben wir bei der Milch. Ich würde mir noch überlegen ob du wirklich den Hersteller mit angeben willst. Falls du mehrere Hersteller kaufst, hast du verschiedene Milchpakete. Da könnte es ausreichen zu speichern: Es ist Milch da.
Oder es kommt eine weitere Gruppe rein, die alles nach der Art der Ware aufteilt. Also Milch, Brot, Bier, Wurst, Seife .... und darunter gibts dann die einzelnen Hersteller. Das erleichtert die Suche ob du noch Produkt X kaufen musst, ganz egal von wem es ist.
Ist die Datenhaltung wirklich der letzte Schritt? Damit wäre ich schon des öfteren reingefallen, denn bei den Überlegungen zur Datenhaltung kommen bereits erste Denkfehler auf.
Man kann das natürlich zuerst auf Klassenebene tun, damit bildet man praktisch auch die Datenhaltung ab und legt schon die Struktur zu einem Großteil fest.
Ich bin da bei Sir Rufo: die Datenbank-Entwicklung kommt nicht als erstes.
Das hat man zugegeben früher getan - und dabei sich oft kein gefallen getan. Macht man heute _eigentlich _großteils nicht mehr.
Als erstes sollte immer die Business Logik kommen, aus der sich die Datenbank ergibt.
Denn die Business Logik ist das, was als erstes aktiv nutzbar ist und den höchsten Mehrwert bietet.
Auch der Agile Entwicklungsgedanke verfolgt ganz klar Business Cases.
Neben der Sache mit MHD, die normalisiert keinen Sinn macht: willst Du EAN wirklich als Nummer abspeicher, obwohl EAN führende Nullen heban kann (USA Präfix 000-009).?
Evtl. übersehe ich etwas, aber sehe hier keinen großen Vorteil von bigint vs string.
Ich kenn Warenwirtschaftssysteme, die speichern das Typbezogen ab: eine Spalte für Identifier (string) und eine für den Typ (Enum, zB EAN).
Die werden sich schon was dabei gedacht haben.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Ja ok nicht als erstes und als letztes ist nicht das selbe 😃
Wir haben eventuell aneinander vorbei geredet. Ich dachte an die Struktur der Daten. Die ist für mich von Beginn an wichtig bzw. sie ergibt sich relativ schnell wenn man die Bedienung der GUI durchdenkt und Klassen designt und sie beeinflusst Aufbau und Bedienung einer Applikation an diversen Stellen.
Wie man das später abspeichert ist in der Tat erst eine Folge des bisher gesagten und braucht nicht der erste Schritt sein. Praktisch gesehen kann sich das immer wieder ändern und erzeugt dann nur unnötigen Aufwand. Aber die Überlegungen was wo einzugeben ist, was mit was wie zusammenhängt usw. halte ich schon für etwas über das man sich bald Gedanken machen sollte.
Er hat auch nicht gesagt "der letzte" (schritt) sondern "einer der letzten".
Und da bin ich bei ihm.
Ich sehe UX und BL deutlich vor der Datenhaltung (bei normalen Desktop-Client-Anwendungen).
Und viel dazwischen gibts nicht...
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Wenn ich mich da jetzt nicht ganz daneben liege, lässt sich die EAN nicht genau auf die Milch in deinem Kühlschrank herunter brechen. Wenn du 5x die gleiche Milch vom gleichen Hersteller hast. Hast du 5x die gleiche EAN aber gegebenen falls 5 Verschiedene MHDs. Ich denke wenn du es richtig machen willst, wirst du der einzelnen Mich eine eigene ID zu ordnen müssen. Um es vielleicht mal grob in UseCases zu beschreiben.
UseCase 1: Einlagern.
Die EAN wird gescannt. Ist sie vorhanden werden, die Werte zur EAN automatisch eingetragen, wenn nicht müssen sie Eingetragen werden. Das MDH muss angegeben werden und das System generiert Automatisch eine ID für genau, die Milch Tüte (als Barcode ausdrucken und auf die Tüte kleben).
UseCase 2: Benutzung
Wenn du Milch aus dem Lager holst, wird dir angegeben welche ID(Barcode) du verwenden solltest, weil dessen MDH als nächstes erreicht wird.
UseCase 3: Auslagern
Beim Auslagern wird die ID (Barcode scannen) angegeben und der Artikel ausgelagert.
Bei den Vorgehen ob man UI, BL oder DAL (Datenbank) zuerst entwickelt, finde ich gibt es keine allgemein gültige Aussage was man zu erst Entwickeln sollte.
Ich persönlich habe da einfach ganz Unterschiedliche Entwicklertypen kennen gelehrt. Bei manchen hat es wirklich am besten Funktioniert wenn sie zuerst die UI hatten und dann BL und DAL Programmiert hatten (Top Down) und andere brauchten erst die Datenstruktur (Bottom Up). Und dazwischen gibt es noch ein paar Unterschiedliche Ansätze.
Persönlich bevorzuge ich es im allgemeinen auch mit dem BL zu beginnen, ich hab aber auch schon festgestellt das es mir grade bei Komplexer BL helfen kann erstmals die Datenstrukturen festzuziehen. Weil es mir dann klare ist mit welchen Werten ich eigentlich Arbeiten kann und was raus kommen soll.
Hinzu kommt, das es auch auf das Projekt ankommt, um festzustellen wo man sinnvoll ansetzt.
Bei einen meine Projekte ging es um die Erfassung und Auswertung von Produktionsdaten.
Der erste Schritt war welche Daten können wir überhaupt erfassen und wie können wir sie sinnvoll Speichern (DAL). Danach kam dann erst welche Auswertung können wir über, diese Daten fahren (BL) und zum Schluss dann wie man sie sinnvoll Anzeigen kann (UI).
Ich persönlich halte es für sinnvoll, mal in allen Ansätzen Erfahrungen gesammelt zu haben und sich dann dafür zu entscheiden was einem Persönlich am besten liegt.
Was natürlich nichts anders sein kann als BL zu erst, ich mach es schließlich ja so 😉
Sollte man mal gelesen haben: