Preisanpassung

[MyRealName]

Eine Preisliste kann (und sollte IMHO) auch aus Kopf- und Detai-Tabelle bestehen.
Im Kopf kommt Gültigkeitsdauer, eventuell KundenId (oder -1 wenn für alle), Name der Liste etc rein.
Im Detail kommt Artikel-ID mit Netto-Verkaufspreis.


Nicht jeder Artikel muss in der Liste stehen, es werden einfach bei der Preisfindung alle für den Kunden gültigen Listen mit dem Artikel durchsucht und der günstigste Preis genommen.

[Luckner]

In diesem Fall Aufschlag für alle Artikel. Ist es jetzt besser (auch für die Zukunft gedacht) in einer Tabelle pro Preisanpassung, jeweils 2 Spalten einzufügen mit DatumAb und Preis? Oder besser pro Preisanpassung eine neue Tabelle mit 2 Feldern zu erzeugen?

Luckner

[MyRealName]

Eine neue Tabelle pro Preisanpassung macht garkeinen Sinn, wie willst denn da ein gültiges SQL bauen. Muss man doch ständig seinen Code anpassen.

Wenn Du es ohne Kopf machen willst (ist dann eben nicht normalisiert), dann halt so

ArtikelId
PreisNetto (der Preis ohne Mwst)
PreisBrutto (Preis mit Mwst, damit Du ihn ohne Rundungsungenauigkeiten als Festwert hast)
GültigVon
GültigBis

Mwst-Satz ist preislistenunabhängig, deswegen eher ein Attribut des Artikels.

[Jasocul]

Da das ein kundenspezifischer Preis ist, würde ich die Kunden-ID mitführen. Es ist zwar im Moment nur ein Kunde, aber sollte ein weiterer dazu kommen, ist das in der Tabelle bereits berücksichtigt.

[Luckner]

Also, soweitich verstanden habe, pro Preisanpassung jeweils die 5 Spalten zufügen?

Luckner

[mikhal]

Dann musst du wieder deinen Code bei jeder Preisänderung anpacken.
Die fügst in die Tabelle Preisliste für jeden Artikel einen neuen Datensatz ein mit dem neuen Preis und dem Datum gültig ab. Beim derzeit gültigen Preis in der Preisliste trägst du in Gültig bis das Datum des neuen Preises -1 ein, so es dieses Feld gibt. Dann hast du eine Chronologie der Preise ohne dass du dir jedesmal die Mühe machen musst, deinen Quelltext anzupassen.

Die Preisfindung realisierst du dann über eine View oder eine Function auf der DB.

Grüße
Mikhal

[Luckner]

Jetzt verstehe ich. Aber bläht sich die Tabelle bei 20.000 Artikel und 3 und mehr Preisanpassungen nicht richtig auf? Nach der 3. Anpsssung sind dann 60.000 Datensätze.

Luckner

[MyRealName]

Da macht man einen Index drauf, dann ist das kein Problem

[mikhal]

Index gesetzt, dann sind das etwa 16 Vergleiche bei 60.000 Datensätzen, bis der Datensatz gefunden wird, dauert bestimmt nicht lang.

Ja, die Tabelle wächst, aber dafür sind Datenbanken konstruiert. Sie sollen große Datenmengen in kurzer Zeit verarbeiten können. Und Speicherplatz war früher das teuerste, heute wird Speicherwachstum kaum noch berücksichtigt. Auch eine so alte Firebird, wie du sie verwendest, kommt schon mit riesigen Datenmengen in angemessener Zeit zurecht - bei entsprechendem RAM und Plattenplatz.

Grüße
Mikhal

[Luckner]

Vielen Dank,

dann werde ich das so machen. In der neuen Software werde ich diese Preisgestalltung ähnlich aufbauen. Auch die anderen Vorschläge (Lieferanten, Mwst-Sätze, usw.) berücksichtigen.

Gruß, Luckner