Forum: Datenbanken
by Hansa,
7. Jun 2011
Das mit den 3 Tabellen war ein Beispiel. Leichter zu programmieren z.B. für Listen : einer will wissen, wieviel Rabatt er auf was kriegt. Bei drei Tabellen würde ich die in absteigender Priorität durchgehen. Das hiesse dann : einfacher Join auf Artikel bzw. Warengruppe.
Ähnlich wäre eine einzelne Rabatttabelle zu behandeln. Flag für Artikel/WG-Rabatt usw.
Dann gäbe es ja noch die...
Forum: Datenbanken
by Hansa,
7. Jun 2011
War klar, dass auch noch Rabatte auftauchen. :P Da geht das Spielchen genau so weiter wie gehabt : ein Rabatt ist grundsätzlich vereinbart, dann braucht man dafür eine Stamm-Table. Solche Strukturen sind dabei nicht unüblich : 10 % Rabatt auf Gemüse (als Waren-Hauptgruppe) und auf Gurken gibt es 15 % (Waren-Untergruppe) und wenn einer spanische Gurken will (Artikel), dann gibt es jetzt 30 %...
Forum: Datenbanken
by Hansa,
6. Jun 2011
Stimmt, aber nur zum Teil. Der Preis kann, muss aber nicht editierbar sein ! Das kommt eben drauf an. Nehmen wir mal Salatgurken, da wird sich der Preis momentan wohl stündlich ändern. :lol:
Da macht das eventuell Sinn, tatsächlich den Preis grundsätzlich editierbar zu machen. Normalerweise ist das aber eher Unsinn und führt zu unnötigen Fehlern. Womöglich kommt noch einer und behauptet, Dein...
Forum: Datenbanken
by Hansa,
6. Jun 2011
Deshalb geht man ja auch hin und spendiert jedem Artikel eine Stückbezeichnung. Also "Stück", "St.", "kg".
Die Preise haben nichts mit den Artikeln direkt zu tun, deshalb gehören sie in separate Tabelle. Leistungsbeschreibungen gehören weder zum Artikel, noch zu der Rechnung an sich. Das muss verknüpft werden mit der Rechnungsposition. Auch hier gilt Verknüpfung Text -> Rechnungspos. über ID...
