[SQL]Kan dit datamodel beter?

[TeeDee]

Voor een interne rekenapplicatie heb ik een Excel sheet gekregen met een stuk of 5 producten met per product een prijs per oplage (500,1000,2500,25000,40000). Dit zijn afgesproken prijzen, maar mocht de gebruiker een oplage van bijvoorbeeld 1500 stuks willen hebben, dan is deze prijs uit te rekenen op basis van het verschil tussen 1000 en 2500 stuks.

Het uiteindelijke resultaat moet worden:

code:

(prijs per stuk * oplage) + transportkosten

Nu moet ik dit vertalen naar een datamodel, alleen vraag ik me af of het e.e.a. beter c.q. efficiënter kan.

tbl_Products

ProductId

PricePerCopy

(ervan uitgaande dat de printprijs te berekenen is op basis van het geselecteerde aantal, en er dus geen commerciële verhoging opzit )

En nu komt imo het lelijke gedeelte om de hoek zetten. De Transport kosten tabel. Omdat de prijs per stuk niet te gebruiken is kom ik er volgens mij niet onderuit om het op deze manier te doen.

tbl_TransportCosts

ProductId

CountryId

TypeOfTransport

Price500

Price1000

Price2500

Price25000

Price40000

Zoals je ziet zijn de kolommen Price{n} vastgelegd in de database omdat het vaste prijsafspraken zijn en de transport wereld op basis van bijvoorbeeld de prijs per pallet rekent. Al zet je 1 doos op de pallet, dan nog is de prijs hetzelfde als voor 200 dozen op diezelfde pallet. (Heel theoretisch dan he ) De kolom TypeOfTransport is een extra variabele. Levering in 72 uur is goedkoper dan levering in 24 uur. De kolom CountryId is ook een variabele. Per land zijn de transport kosten anders.

Globaal gezien komt er in de Transport tabel het volgende te staan:

ProductId	CountryId	TypeOfTransport	Price500	Price1000	etc. etc.
1	1	1	€500	€1000	...
1	1	2	€550	€1050	...
2	1	1	€400	€900	...
2	1	2	€450	€950	...

prijzen zijn fictief en zijn nooit zo netjes afgerond natuurlijk.

Ben er nu al geruime tijd mee aan het spelen en persoonlijk zie ik echt geen andere optie/mogelijkheid meer. Het makkelijkste had geweest als we voor het transport ook de prijs per stuk hadden geweten, maar dat is dus niet zo.

Verder is met deze opzet een wijziging in het datamodel (dus bijvoorbeeld Price1500, een extra kolom) nog wel te overzien en lijkt me voor de applicatie ook geen wijziging nodig.

Dus: kan bovenstaand datamodel anders of is dit niet te verbeteren?

[Dido]

Dat lijkt me een standaard staffelsysteem?

Maak een tabel met per product een aantal staffels (1 record per staffel dus) en de prijs per stuk.

dus iets als

code:

Product  Staffel Prijs/stuk
1          500    1.2
1         1000    0.9
1         2000    0.6

Je totaalprijs bepaal je dan door de stuksprijs uit deze tabel te zoeken (de prijs behorend bij de grootste staffel <= het aantal) en te vermenigvuldigen met het aantal.

[ Voor 24% gewijzigd door Dido op 26-04-2007 12:02 ]

[whoami]

* whoami ging net hetzelfde typen als Dido.
Bijhouden wat de kosten zijn per eenheid. Op die manier kan je
a) de prijzen makkelijk wijzigen (wat je met uw voorstel ook kon)
b) makkelijk een nieuwe prijs introduceren zonder het datamodel te moeten aanpassen

[TeeDee]

Ik moet inderdaad nog een staffel tabel plaatsen. Het is helaas niet zo dat de prijs per stuk uit te rekenen is (opstartkosten, drukplaten etc. etc.). Vandaar ook de melding:

(ervan uitgaande dat de printprijs te berekenen is op basis van het geselecteerde aantal, en er dus geen commerciële verhoging opzit )

Maar ik maak me meer zorgen eigenlijk om de tbl_TransportCosts, persoonlijk denk ik dat het niet anders kan.

whoami schreef op donderdag 26 april 2007 @ 12:06:
* whoami ging net hetzelfde typen als Dido.
b) makkelijk een nieuwe prijs introduceren zonder het datamodel te moeten aanpassen

En dat is meteen de belangrijkste. Ik gok er namelijk op dat als deze module opgeleverd wordt, de prijzen compleet anders zijn.

[Dido]

TeeDee schreef op donderdag 26 april 2007 @ 12:16:
Ik moet inderdaad nog een staffel tabel plaatsen. Het is helaas niet zo dat de prijs per stuk uit te rekenen is (opstartkosten, drukplaten etc. etc.). Vandaar ook de melding:

Dergelijke kosten zijn toch eenvoudig apart op te slaan?

De prijs per stuk in je staffeltabel is dan niet de daadwerkelijke prijs per stuk, maar dat boiet niet.

Gewoon je prijs per (500 - opstartkosten - anderekosten) / 500 in je staffeltabel zetten dus.
Evenzo (1500 - opstartkosten - anderekosten) / 1500.

[TeeDee]

Dido schreef op donderdag 26 april 2007 @ 12:34:
[...]

Dergelijke kosten zijn toch eenvoudig apart op te slaan?

De prijs per stuk in je staffeltabel is dan niet de daadwerkelijke prijs per stuk, maar dat boiet niet.

Gewoon je prijs per (500 - opstartkosten - anderekosten) / 500 in je staffeltabel zetten dus.
Evenzo (1500 - opstartkosten - anderekosten) / 1500.

En die kosten weet ik niet. Ik heb bijvoorbeeld:

2500 cps voor Product 1 een prijs van €773.42,- (excl. transport)
25000 cps voor Product 1 een prijs van €2184.37,- (excl. transport)

Oplage: 14.500
prijs(25000)-prijs(2500)=€1410,95 / 22500= €0.062 p/s * 14.500 = €783.86 + €773.42 = +/- €1557,-

^^ Dat is/wordt de berekening als ik het goed heb.

Update: Ik heb alleen de stuksprijs per staffel nodig. Zoals gezegd inmiddels. Dat is me zojuist verteld want in de stuksprijs zitten dat soort zaken blijkbaar al meegerekend.

Concluderend:
• Een extra staffel tabel toevoegen met de prijs per stuk, aantal en vervolgens de mogelijkheid om met een BETWEEN oid de prijs op zoeken mocht de oplage afwijken van de vooraf gegeven staffel prijs.

Op die manier is de database makkelijk uit te breiden.

[DamadmOO]

TeeDee schreef op donderdag 26 april 2007 @ 13:07:
En die kosten weet ik niet. Ik heb bijvoorbeeld:

2500 cps voor Product 1 een prijs van €773.42,- (excl. transport)
25000 cps voor Product 1 een prijs van €2184.37,- (excl. transport)

Oplage: 14.500
prijs(25000)-prijs(2500)=€1410,95 / 22500= €0.062 p/s * 14.500 = €783.86 + €773.42 = +/- €1557,-

^^ Dat is/wordt de berekening als ik het goed heb.

offtopic:
Ik mag toch hopen dat je die stukprijs eerst met 12000 vermenigvuldigt ipv 14500. Nu betaal je 2500 exemplaren dubbel

[TeeDee]

DamadmOO schreef op donderdag 26 april 2007 @ 18:49:
[...]

offtopic:
Ik mag toch hopen dat je die stukprijs eerst met 12000 vermenigvuldigt ipv 14500. Nu betaal je 2500 exemplaren dubbel

offtopic:
mjah, zoiets zou het moeten zijn.

[ Voor 13% gewijzigd door TeeDee op 26-04-2007 18:54 ]

[Guru Evi]

Persoonlijk vind ik dat je geen datamodel meer aan het maken bent, je hebt een enorm archaisch datamodel meegekregen van je klant of via de Excel file. Wat ik zou doen is terug naar je klant gaan en uitleggen dat het efficienter zal zijn zoals de voorbeelden hierboven, neem de transport en opstartkosten apart van de stukkosten. Dat is zowel vanuit een economisch standpunt als een datamodel standpunt beter, zij kunnen dan snel alle kosten automatisch aanpassen indien de vaste transportkosten verhogen.

[mr.inno]

Guru Evi schreef op maandag 30 april 2007 @ 20:22:
Persoonlijk vind ik dat je geen datamodel meer aan het maken bent, je hebt een enorm archaisch datamodel meegekregen van je klant of via de Excel file. Wat ik zou doen is terug naar je klant gaan en uitleggen dat het efficienter zal zijn zoals de voorbeelden hierboven, neem de transport en opstartkosten apart van de stukkosten. Dat is zowel vanuit een economisch standpunt als een datamodel standpunt beter, zij kunnen dan snel alle kosten automatisch aanpassen indien de vaste transportkosten verhogen.

ja maar niet elke klant wil dit. Het implementeren hier van kan overgens heel veel tijd innemen.

veelvoud prijs delen door aantal en dat opslaan in staffel tabel is veel makkelijker en verantwoord genoeg voor in het model

[TeeDee]

Guru Evi schreef op maandag 30 april 2007 @ 20:22:
Persoonlijk vind ik dat je geen datamodel meer aan het maken bent, je hebt een enorm archaisch datamodel meegekregen van je klant of via de Excel file. Wat ik zou doen is terug naar je klant gaan en uitleggen dat het efficienter zal zijn zoals de voorbeelden hierboven, neem de transport en opstartkosten apart van de stukkosten. Dat is zowel vanuit een economisch standpunt als een datamodel standpunt beter, zij kunnen dan snel alle kosten automatisch aanpassen indien de vaste transportkosten verhogen.

De transportkosten zijn nu toch gescheiden van de andere kosten?