Macht dieses ER Modell Sinn? Kunde, Lieferschein, Rechnung

Werbung:
Telefon INT.

Ansonsten: schön bunt. Keine Ahnung, was da dann nun PK und FK sind, wo Indexe sind, welche Abfragen kommen, was das Ziel der Übung ist etc. Kann damit nicht viel anfangen.
 
Sieht eher unbrauchbar aus.

PLZ als INT geht gar nicht.
Land fehlt.
Bestellung/Auftrag fehlt, der ist ja eigentlich die Grundlage für jede Lieferung.
Was soll die Rechnungsnummer im Artikelstamm?
Warum eine 1:1 Beziehung von Rechnung und Lieferschein?
Was ist ein Caddy und warum eine 1:1 Beziehung zu Kunde und Lieferschein?
 
Ich brauche die PLZ ausschliesslich für vierstellige Nummern, braucht weniger Memory als VARCHAR.
Ein validierter Warenkorb oder Caddy ist eine Bestellung, ist noch nicht vollständig. Ich werde das heute noch überarbeiten müssen. Die Kundennummer im Artikel ist der von Workbench generierte Relationsschlüssel.

Betreffend den Beziehungen sollte ich mal erklären, was das Modell eigentlich soll

Ein Kunde hat genau einen Caddy. Ein Caddy kann mehrere Artikel enthalten. Ein validierter Caddy ist eine Bestellung und hat genau eine Rechnung, welche genau einen Lieferschein hat.

Die Geschäftslogik ist darauf angelegt, Service Produkte (welche Artikel beinhalten können) anbieten zu können. Es wird jedes Produkt mit seinen Artikeln mit dem Kunden assoziiert und bei einem Problem können technische Daten und die Konfiguration angezeigt werden. Es geht um den Service und die Unterstüztung des Kunden.

MySQL Workbench generiert dann mit dem Forward Engineering den SQL Befehl zum Erzeugen der Tabellen.
Anschliessend will ich mit Python ein Interface machen.

Also, ich melde mich wieder, wenn es besser aussieht
 
Werbung:
Ein Kunde hat genau einen Caddy. Ein Caddy kann mehrere Artikel enthalten. Ein validierter Caddy ist eine Bestellung und hat genau eine Rechnung, welche genau einen Lieferschein hat.

Das bedeutet, dass jeder Kunde genau einmal bestellen kann und dann nie wieder - nicht sehr realistisch

Was ist wenn der Kunde nachträglich weitere Artikel bestellen möchte? Veränderst Du dann bestehende Bestellungen und Rechnungen (was steuerrechtlich sehr fragwürdig wäre)

Typischerweise hat ein Kunde viele Bestellungen und zu jeder Bestellung mindestens eine Rechnung. Wenn man Teillieferungen abbilden will, dann gibt es eventuell mehr als eine Rechnung pro Bestellung und mit Sicherheit mehr als einen Lieferschein.

Die Zuordnung zwischen Caddy (Warenkorb/Bestellung) und Artikel muss über eine M:N Relation gehen. Momentan kann jeder Artikel genau einmal von genau einem Kunden gekauft werden - ich kann mir nicht vorstellen, dass das gut für's langfristige Geschäft ist.

Die "Optimierung", die Postleitzahl als Integer zu speichern ist lobenswert, aber ein typischer Fall von "frühzeitiger" Optimierung und macht heutzutage keinen wirklichen (messbaren) Unterschied.

Besser wäre vielleicht eine dedizierte Lookup Tabelle für Postleitzahlen, und "kunde" speichert nur einen Fremdschlüssel auf die Tabelle (was dann wieder ein INT wäre).
 
Zurück
Oben