Datenbankaufbau für Verkaufsprogramm

[Laessnig 0]

Liebe SQL Freunde!

 

Ich bin momentan dabei, ein Java Programm zu entwickeln, welches es den Kunden eines Selbstbedinungsladen erlauben soll Produkte selbstständig abzuscannen und zu bezahlen - Ähnlich wie bei den Kassen, an denen man als Kunde seine Produkte selber bezahlen kann. (Merkur etc.)

Im Hintergrund rennt eine MySQL Datenbank, welche für die gesamte Bestandsführung / Lagerlogistik usw. verantwortlich ist.

Nun habe ich jedoch folgendes Problem:

 

Jeder Produktanbieter muss seine Produkte selbstständig in den Warenbestand hinzufügen / Warten. 

Jetzt gibt es aber einerseits Produkte, dessen Preis durch das Gewicht bestimmt wird (Fleisch usw.), aber auch welche, welche nach Stück abgerechnet werden (Glas Honig...)

Nun meine Frage:

Wie sollte ich die Datenbanktabellen am besten entwerfen?

Zurzeit hat jedes Produkt einen fixen Preis, allerdings wird das ganze so nicht funktionieren. 

 

Bitte um Hilfe - Danke im Voraus :)

lg

[NilsK 2.784]

Moin,

 

ist das eine Lernaufgabe? Oder geht es um was Produktives?

 

Für mich klingt das nach einer Basisfrage zum Datenbankdesign, die mich überrascht, wenn es um eine lauffähige Anwendung mit dem genannten Einsatzzweck geht. Wie weit bist du mit Datenmodellierung vertraut?

 

Gruß, Nils

 

[Laessnig 0]

Hallo!

 

Das Problem ist, dass das alles jetzt schon so viel Arbeit in Anspruch genommen hat (Java Implemetierung), dass ich nicht wieder von vorne anfangen will ... 

 

[DerFrank 15]

vor 18 Stunden schrieb Laessnig:

Hallo!

 

Das Problem ist, dass das alles jetzt schon so viel Arbeit in Anspruch genommen hat (Java Implemetierung), dass ich nicht wieder von vorne anfangen will ... 

 

H

.. wenn das so ist, dann nimm am einfachsten ein feld "gewicht" mit in deine produkttabelle auf.

Artikel, die nach stück verkauft werden, bleibt dann das "gewicht" eben leer (null).

 

Aber eigendlich solltest du dir immer zuerst das datenmodel überlegen bevor gecodet wird... habe auch so angefangen... aber man lernt immer dazu. 

 

Vg

DerFrank

bearbeitet 13. September 2018 von DerFrank

[Laessnig 0]

Lieber Frank!

 

Ich danke dir rechtherzlich für deine Antwort. 

Leider war das Model für die Anforderung eigentlich passend, jedoch hat sich diese geändert, nachdem das Projekt zu 90% abgeschlossen war. ...
Deine Idee ist wirklich super und genau so werde ich das auch machen.

lg

 

[Dukel 436]

Dann kommt irgendjemand her und möchte Meterware verkaufen oder Gram / Tonnen statt ;)

 

Wie wäre es mit einem Feld Einheit und einem Feld Preis. Und bei einem Teil kommt als Einheit 1, bei einem 5kg schweren Gerät 5 und bei einem 10 meter langem Stoff die 10 hinein. Evtl. noch ein Feld für die Einheitsbeschreibung (stück, kg oder meter).

[NilsK 2.784]

Moin,

vor 41 Minuten schrieb Dukel:

Wie wäre es mit einem Feld Einheit und einem Feld Preis. Und bei einem Teil kommt als Einheit 1, bei einem 5kg schweren Gerät 5 und bei einem 10 meter langem Stoff die 10 hinein. Evtl. noch ein Feld für die Einheitsbeschreibung (stück, kg oder meter).

auch zu kurz gedacht. "Einheit" ist eine Einheit, also Gramm, Meter oder was immer. Keine Zahl. Die Zahl in deinem Beispiel wäre ein separates Feld "Anzahl" - das hat aber in der Artikeltabelle nichts zu suchen, weil es eine Eigenschaft einer konkreten Bestellung bzw. eines Einkaufs ist (separates Objekt, separate Tabelle(n)).

 

Nun wird man schnell feststellen, dass "Einheit" vielleicht lieber in einer separaten Tabelle stehen sollte, die 1:n mit der Artikeltabelle verknüpft ist. Vielleicht will man dann noch steuern, ob eine Einheit auch teilbar ist oder nicht (1,5 kg kann es etwa bei Mehl geben, aber vielleicht gibt es Artikel, die man nur in ganzen Metern verkaufen kann und nicht in halben). Und bei der Gelegenheit merkt man, dass es ohne ein konzentriertes Datenmodell eben nicht geht.

 

Gruß, Nils

 

bearbeitet 13. September 2018 von NilsK