Tabellenaufbau eines Rechnungssystems
-
Hi Leuts!
wir nehmen gerade die 3. Normalform für SQL in der Berufsschule durch und haben diverse Aufgaben dazu bekommen. Bisher kein Problem, jedoch bei einer Aufgabe verzweifle ich etwas und komme nicht so recht weiter.
Drum poste ich besser erst mal die Aufgabenstellung und danach meinen Entwurf.
Strukturieren Sie den Tabellenaufbau eines Rechnungssystems. In dem System werden Artikel (article) verwaltet, welche einen Namen und einen Preis besitzen. Diese Artikel können als Positionen (position) in einer Rechnung (purchase) aufgelistet werden mit ihrer erworbenen Anzahl. Artikel können jedoch auch in einem Paket (bundle) mit anderen Artikeln in einer Stückzahl erworben werden. Die erworbenen Pakete sind ebenfalls Positionen auf der Rechnung.
Soweit sogut, leider bekomme ich keine gute Kombination zwischen Artikel und dem Paket hin um diese in der Position zu vereinheitliche.
Aber erstmal mein Tabellenaufbau
==================== article ==================== - id(pk) - name // Name - price // Preis ==================== bundle ==================== - id(pk) - name // Name - price // Preis ==================== article-to-bundle ==================== - bundle.id (pk-fk) - article.id (pk-fk) - article-count // Anzahl von diesem Artikel in dem Bundle ==================== position ==================== - id (pk) - purchase.id (fk) - article-count // Anzahl von diesem Artikel/Bundle in dieser Position { - article.id (fk) - bundle.id (fk) } ==================== purchase ==================== - id - date // Rechnungsdatum
Wie man sieht hänge ich an der Position. Soll ich in der Position 2 Foreignkeys machen (einer für Artikel und einer für Bundle) und dann je nachdem einen auf NULL setzen? Weil es kann entweder nur ein Artikel sein oder ein Bundle, aber nie beides oder keines.
Bin für jeden Vorschlag dankbar.
Viele Grüße,
EasyCoder
-
Ein Ansatz wäre es, die Artikel auch als einteiilige Bundles zu betrachten. Eine andere Lösung, die bei uns mehrfach vorkommt, ist die Kombination wohertyp+fkwoher (dabei gibt der Typ an, auf welche Tabelle sich der Fremdschlüssel bezieht).
-
Die praktikabelste Lösung ist meiner Meinung nach einen Artikel auch als einteiliges Bundle zu sehen.
Weil wenn ein Bundle aus Artikeln besteht kannst du das Bundle ja auch als eigentlichen Artikel bezeichnen.
Dieses Artikelbundle besteht dann halt aus einem oder mehreren Artikeln.
-
@CStoll
Danke für deinen Post! Ich denke ich werde diese Lösung mit "Wohertyp" und K nehmen, da ich diese denke ich sehr gut über einen left join kombinieren kann.