[Database] Order tabel redundante gegevens?

[ZeroXT]

Ik ben een online kassa een het maken waarbij een verkoop bestaat uit een datum, klantgegevens, betalingsgegevens en productgegevens.

Nu is er een klantentabel en productentabel. Echter kan het voorkomen dat klantgegevens of productgegevens (met name prijzen) gewijzigd worden. Wanneer de bon opnieuw uitgeprint wordt, moeten de originele gegevens weer op de bon afgedrukt worden.

Dus wanneer klant A product B voor een prijs van €10.00 koopt dan moeten deze gegevens over bijvoorbeeld één jaar exact weer zo op de bon geprint worden wanneer deze nogmaals wordt afgedrukt.

Nu had ik zelf het idee om een order tabel aan te maken die al deze gegevens opslaat zoals ze op dat moment zijn. Maar is dit wel the way to go? Want dan worden de gegevens eigenlijk dubbel opgeslagen. Zijn hier database designpatterns voor?

Ik zal niet de enige zijn met dit probleem dus vroeg me af of iemand mij een schopje in de juiste richting wilt geven

[weebl]

Het zijn toch verschillende gegevens? Dat noem ik dan niet redundant hoor Je hebt dan toch $prijsproduct_datumaanschaf en $prijsproduct_datumhuidig? De eerste sla je op in de tabel met orders en de tweede staat in de tabel met producten.

Of snap ik het niet?

[Nielsvr]

Wij slaan dit apart op;

customers
- ID
- name
- etcetera

orders
- ID
- customer_ID
- date
- etcetera

order_lines
- ID
- order_ID
- title
- quanity
- price
- etcetera

Het is niet redunant, want het betreft geen product meer maar een order item. Andere inhoud en bestemming.

[NMe]

Wat ik normaal gesproken doe is een Factuur-tabel, een FactuurRegel-tabel en een Adres-tabel. Elke keer als een klant zijn adres wijzigt maak ik een nieuw record in die adrestabel en update ik het klantrecord om daarnaar te verwijzen. Bestaande facturen blijven gewoon naar de bestaande adressen wijzen, ook als die dus niet meer gebruikt worden.

Hetzelfde geldt voor prijzen, al maak ik daar geen tabel voor aan. Op de factuurregel zelf neem ik over wat de stukprijs en het aantal stuks is, en in de omschrijving van de regel neem ik de productnaam over zoals die is op het moment van aanmaken.

[Gomez12]

ZeroXT schreef op donderdag 05 juni 2014 @ 14:09:
Nu had ik zelf het idee om een order tabel aan te maken die al deze gegevens opslaat zoals ze op dat moment zijn. Maar is dit wel the way to go? Want dan worden de gegevens eigenlijk dubbel opgeslagen. Zijn hier database designpatterns voor?

De truc is dus zoals al gezegd dat de gegevens niet dubbel opgeslagen worden, het ene gegeven is huidig en het andere is historisch.

Het kan dubbel lijken, maar dat is maar tijdelijk. Als morgen iemand de omschrijving van product a en b omwisselt dan moet jouw order toch nog steeds de juiste info bevatten.
Wijzigt de regering het btw percentage dan moet jouw order nog steeds hetzelfde btw-percentage bevatten.
Is de klant verhuist maar komt er discussie over een order dan is het toch wel makkelijk als je richting de vervoerder kan vragen of die op die dag op adres x is geweest ipv dat je enkel het huidige adres ziet.

Ook een leuke die ik weleens tegenkom is bijv : Geholpen door en dan een personeelslidsnaam, in principe wordt een personeelslid nooit verwijdert dus je houdt altijd de oude personeelsledennamen. En sommige programmeurs verwachten ook niet dat iemands naam gaat veranderen, maar sommige vrouwen die willen bijv nog wel eens trouwen, dus al meerdere projecten gezien waar de personeelsnamen ook in de ordertabel erbij moesten.

[thaan]

Wat hierboven al gezegd wordt, wordt ook in de opensource shopping cart systemen die ik zie gedaan.

- 1 tabel voor producten
- 1 tabel voor orders
- 1 tabel voor de bestelde producten uit die orders (dus 1 row voor product X uit order Y, en nog een keer een row voor product X uit order Z)

[Staatslot]

Ik zie naast bovengenoemde oplossing ook tabellen met historische prijzen per product. Zodoende kun je daar ook iets mee doen..

[P_Tingen]

Als je het echt netjes wil doen dan moet je een ingangsdatum opnemen bij alle data die op je bon terecht komt, maar vergis je niet, want alleen een ingangsdatum is niet genoeg. René Veldwijk schreef ooit al in zijn 10 geboden voor database ontwerpers: "Gij zult het historieprobleem vrezen" *). En terecht.

Ga maar even na met dit horrorscenario.

1 februari	ik koop bij jou een konijnenhok. Volgens jouw systeem is mijn adres "Brink 14"
10 februari	Ik ontdek dat er iets mis is met het hok en bel met de winkel. En passant geef ik door dat het adres op mijn bon niet klopt, want ik ben op 1 januari verhuisd naar "Dorpsstraat 8". Jij vertelt mij dat je het aanpast.
14 februari	Er is echt iets mis met het hok en ik kom het ruilen.

Welk adres komt er nu op de bon?

Als ik op 10 februari bel, maak jij een adreswijziging voor mij aan en je zet in het systeem dat ik per 1-1 ben verhuisd. Probleem is alleen dat als je op 14-2 een bon van mij uitprint, daar niet hetzelfde adres opstaat als op 1-2.

Ziehier het probleem in een notedop. Je moet - als je het goed wil doen - niet alleen een datum in je systeem opnemen waarop de wijziging ingaat, maar ook een datum waarop het voor het systeem bekend is. Vervolgens heb je dus allerlei mogelijkheden met deze twee datums, want zoals bovenstaand voorbeeld laat zien kan de ingangsdatum zowel voor als na de weet-datum liggen. Daarom moet je volgens Veldwijk het historieprobleem dan ook vrezen.

Wat kun je nu het beste doen? Ik denk dat je het beste alle gegevens van de bon in een aparte tabel / tabellenset moet opslaan, los van je gewone data. Dan weet je 100% zeker dat je de bon kunt reproduceren en heb je geen ingewikkelde constructies nodig in je database.

*) Boek is niet meer leverbaar, maar als je wil stuur me een dm voor de pdf van de losse artikelen, als ik die kan vinden.

[thaan]

P_Tingen schreef op donderdag 05 juni 2014 @ 21:08:
Als je het echt netjes wil doen dan moet je een ingangsdatum opnemen bij alle data die op je bon terecht komt, maar vergis je niet, want alleen een ingangsdatum is niet genoeg. René Veldwijk schreef ooit al in zijn 10 geboden voor database ontwerpers: "Gij zult het historieprobleem vrezen" *). En terecht.

Ga maar even na met dit horrorscenario.

1 februari	ik koop bij jou een konijnenhok. Volgens jouw systeem is mijn adres "Brink 14"
10 februari	Ik ontdek dat er iets mis is met het hok en bel met de winkel. En passant geef ik door dat het adres op mijn bon niet klopt, want ik ben op 1 januari verhuisd naar "Dorpsstraat 8". Jij vertelt mij dat je het aanpast.
14 februari	Er is echt iets mis met het hok en ik kom het ruilen.

Welk adres komt er nu op de bon?

Als ik op 10 februari bel, maak jij een adreswijziging voor mij aan en je zet in het systeem dat ik per 1-1 ben verhuisd. Probleem is alleen dat als je op 14-2 een bon van mij uitprint, daar niet hetzelfde adres opstaat als op 1-2.

Ziehier het probleem in een notedop. Je moet - als je het goed wil doen - niet alleen een datum in je systeem opnemen waarop de wijziging ingaat, maar ook een datum waarop het voor het systeem bekend is. Vervolgens heb je dus allerlei mogelijkheden met deze twee datums, want zoals bovenstaand voorbeeld laat zien kan de ingangsdatum zowel voor als na de weet-datum liggen. Daarom moet je volgens Veldwijk het historieprobleem dan ook vrezen.

Wat kun je nu het beste doen? Ik denk dat je het beste alle gegevens van de bon in een aparte tabel / tabellenset moet opslaan, los van je gewone data. Dan weet je 100% zeker dat je de bon kunt reproduceren en heb je geen ingewikkelde constructies nodig in je database.

*) Boek is niet meer leverbaar, maar als je wil stuur me een dm voor de pdf van de losse artikelen, als ik die kan vinden.

Inderdaad, een bestelling in een DB hoort gewoon een kopie te zijn van alle bekende data. Van klantinformatie, tot betaalmethode en bedrag, tot factuur- en leveradres.
Dan kun je de klant verwijderen, producten verwijderen, maar de factuur gewoon repliceren: historieprobleem weg.

[Gomez12]

P_Tingen schreef op donderdag 05 juni 2014 @ 21:08:
Vervolgens heb je dus allerlei mogelijkheden met deze twee datums, want zoals bovenstaand voorbeeld laat zien kan de ingangsdatum zowel voor als na de weet-datum liggen. Daarom moet je volgens Veldwijk het historieprobleem dan ook vrezen.

Ik ken de beste Hr Veldwijk niet, maar ik zie totaal niet in wat er te vrezen valt aan "het historieprobleem". Het is namelijk bijna geen probleem als je de volgende stelregel hanteert :
- Normaliseer enkel iets wat voor nu en altijd op dezelfde plek hetzelfde blijft. Anders niet normaliseren

Het door jou benoemde historieprobleem zie ik alleen als een probleem als je database normalisatie niet snapt en het overal denkt te moeten doorvoeren.

[Gomez12]

thaan schreef op donderdag 05 juni 2014 @ 22:05:
[...]

Inderdaad, een bestelling in een DB hoort gewoon een kopie te zijn van alle bekende data. Van klantinformatie, tot betaalmethode en bedrag, tot factuur- en leveradres.
Dan kun je de klant verwijderen, producten verwijderen, maar de factuur gewoon repliceren: historieprobleem weg.

Let er wel op dat je veelal een verschil hebt tussen een lopende bestelling en een afgehandelde order (en een paar stadia daartussenin)

Een afgehandelde order moet je alles gedupliceerd hebben, maar een bij een lopende bestelling kan die overweging weer anders zijn.
Als er bijv een lopende bestelling (nog niet uitgeleverd) in het systeem staat en de klant belt een adreswijziging door dan is het veelal weer niet handig om naast de relatie-gegevens ook alle openstaande orders aan te passen. Maar bijv een prijswijziging van een leverancier kan je veelal wel weer doorvoeren (/communiceren) als de order nog niet uitgeleverd is, maar na uitlevering en voor facturering mag de prijs weer niet aangepast worden.

Oftewel in de meeste "grotere" systemen die ik ken (ik ken geen kleintjes) hanteren ze rustig meerdere kopieen over dezelfde order.
- Ze hebben de basisgegevens (product / klant / etc)
- Ze hebben een ordertabel met daarin alle product gegevens gekopieerd (en menig verkoper kan die gegevens aanpassen bij invoeren order), deze heeft meestal nog geen klant-gegevens
(- Dan veelal nog een orderpick tabel waarin aangegeven wordt wat er daadwerkelijk uit het magazijn gehaald is voor het updaten van de basistabel qua voorraad en voor het kunnen tonen van wat de klant besteld heeft en wat er geleverd is)
- En dan heb je in principe altijd nog een factuurtabel, hierin is alles gedupliceerd en staat alles hard vast.en hieruit wordt dan ook de bon geprint, doordat alles vast staat is de 2e uitdraai altijd gelijk aan de 1e omdat de data gelijk is. Hier komen ook geen adreswijzigingen meer op door etc, een adreswijziging betekent gewoon credit en nieuwe factuur (wat je dan desgewenst wel weer kan doen vanuit dezelfde bon).

En de koppelingen tussen deze tabellen zijn ook allemaal n:n omdat elk gedeelte zo ongeveer opgesplitst kan worden naar meerdere vervolgdelen (als er bijv een bestelling is van 10 artikelen, maar 5 zijn er op voorraad, 2 komen over 2 maanden binnen en 3 komen er over 6 maanden binnen dan kan je best 3 facturen willen maken)

Maarja, in mijn wereld heb je aan de inkoopkant zo ongeveer iets gelijkwaardigs, aangezien je iets kan inkopen in duitsland (met een duitse omschrijving) terwijl je het wil verkopen met een nederlandse omschrijving en die omschrijvingen kunnen dan ook weer eens wijzigingen tussen moment van bestelling en inkooporder en inkoopfactuur.

[ZeroXT]

Hartelijk bedankt voor alle antwoorden. Ik heb inmiddels een keus gemaakt door alle gegevens op te slaan in een enkele tabel en dit niet te zien als redundante gegevens.

Echter heb ik nog één vraag:

Stel dat het bedrijf (en met bedrijf bedoel ik niet de klantgegevens maar het bedrijf waar de klant het product koopt) gaat verhuizen. Moeten dan de oude adresgegevens van het bedrijf ook op de bon/offerte/factuur geprint worden wanneer deze opnieuw wordt uitgeprint? Of moeten dan de nieuwe adresgegevens van het bedrijf op de bon/factuur/offerte komen?

[ Voor 10% gewijzigd door ZeroXT op 16-06-2014 15:13 ]

[Nielsvr]

Ook die gegevens slaan wij op als "order". Aangezien je wil terug zien waar een order geplaatst is of naar toe gestuurd is, ook als deze gewijzigd zijn. Consistentie is hierin belangrijk (al zijn er ook methodes waarin je versioning achtige oplossing doet, met datums van wijzigingen van adressen.)

[NMe]

ZeroXT schreef op maandag 16 juni 2014 @ 15:11:
Hartelijk bedankt voor alle antwoorden. Ik heb inmiddels een keus gemaakt door alle gegevens op te slaan in een enkele tabel en dit niet te zien als redundante gegevens.

Echter heb ik nog één vraag:

Stel dat het bedrijf (en met bedrijf bedoel ik niet de klantgegevens maar het bedrijf waar de klant het product koopt) gaat verhuizen. Moeten dan de oude adresgegevens van het bedrijf ook op de bon/offerte/factuur geprint worden wanneer deze opnieuw wordt uitgeprint? Of moeten dan de nieuwe adresgegevens van het bedrijf op de bon/factuur/offerte komen?

Die oude adressen moeten op de factuur blijven staan, ja. Je moet ofwel de originele factuur opslaan, ofwel hem opnieuw kunnen genereren.

[Gomez12]

ZeroXT schreef op maandag 16 juni 2014 @ 15:11:
Echter heb ik nog één vraag:

Stel dat het bedrijf (en met bedrijf bedoel ik niet de klantgegevens maar het bedrijf waar de klant het product koopt) gaat verhuizen. Moeten dan de oude adresgegevens van het bedrijf ook op de bon/offerte/factuur geprint worden wanneer deze opnieuw wordt uitgeprint? Of moeten dan de nieuwe adresgegevens van het bedrijf op de bon/factuur/offerte komen?

Dan heb ik eigenlijk maar 1 wedervraag :
Stel dat de klant een factuur gaat betwisten en jij gaat naar PostNL / je vervoerder met jouw kopie factuur om bewijs te halen, hoeveel bewijs denk je dan dat je vervoerder gaat vinden op het nieuwe adres?

[ZeroXT]

Ok duidelijk. Erg bedankt voor alle nuttige antwoorden! Ik kan weer verder.