[SQL] Opbouw database, hoe? - Softwareontwikkeling

donderdag 20 juli 2006 10:17

Acties:

Topicstarter

Hoi,

ik ben bezig met een online order-systeem voor een bedrijf. Nu had ik een vraag over hoe ik het beste mijn database kan inrichten.

Ik heb:

klanten
- id
- naam
- btwnr
producten
- id
- naam
- prijs

Het probleem is dat de prijs van producten verschilt per klant. Mijn vraag is: hoe kan ik het beste de tabellen inrichten? Mijn voorstel:

klanten-tabel
producten-tabel (zonder prijs)
tabel die prijs koppelt aan producten-id en klanten-id

Die derde tabel wordt wel errug lang en smal zo (bijv. 100 producten, 100 klanten = 10.000 rows). Is dat een probleem? Of moet ik de tabellen anders inrichten?

donderdag 20 juli 2006 10:19

Acties:

P_de_B

Je hebt het goed idee

Er zijn nog wel andere oplossingen gebruikelijk (zoals een standaard prijs, en dan juist weer kortingen etc) maar je idee van een koppeltabel met daarin de specifieke prijs voor een klant/productcombinatie is goed. 10.000 rijen is echt peanuts.

Oops! Google Chrome could not find www.rijks%20museum.nl

donderdag 20 juli 2006 10:21

Acties:

Salandur

Software Engineer

je krijgt natuurlijk ook orders:
order
- id
- klantid
- korting
- datum

met orderregels:
orderregel
- id
- orderid
- productid
- prijs (per stuk)
- aantal

op deze manier heb je een redelijk completer systeem, omdat je nu kan zien wat een klant op een bepaald moment heeft besteld en ook per product wat de klant ervoor heeft betaald (de prijs op dat moment)

Assumptions are the mother of all fuck ups | iRacing Profiel

donderdag 20 juli 2006 10:24

Acties:

Pascal Saul

Ik zou de prijzen on the fly uitrekenen dus met een korting werken.

Dat ligt er natuurlijk ook aan hoe vaak prijzen worden geupdate. Als je met korting werkt hoef je eenmalig de korting te veranderen en het systeem doet de rest.

Aan de andere kant als je ze los opslaat kan je deze incidenteel wijzigen. Maar die vraag kan je het beste aan de klant stellen

Je zou zelfs nog alle prijzen opslaan en dat een update query doen als je de korting veranderd. Wel ben je dan de incidentele prijzen kwijt maar is wel iets flexibeler

[ Voor 20% gewijzigd door Pascal Saul op 20-07-2006 10:29 ]

donderdag 20 juli 2006 10:28

Acties:

The - DDD

Hou rekening met het feit dat prijzen kunnen wijzigen, maar dat bestaande/oude orders tegen de op dat moment geldende prijs bewaard moeten worden. Zoals Salandur voorstelt dus.

donderdag 20 juli 2006 10:30

Acties:

Rekcor

Topicstarter

@P_de_B

10.000 rijen is echt peanuts

Oke. Wanneer wordt het oppassen geblazen? 100.000 rijen? 1.000.000 rijen? Heb zelf tot nu toe alleen nog maar een CMSje gemaakt, en die kwam niet boven de 1000 rijen uit...

@Salandur

Klopt, er zitten natuurlijk nog meer tabellen in het systeem. Wilde het evenwel zo simpel mogelijk houden hier i.v.m. de vraag.

@alle vier

Bedankt voor jullie reacties! $_/-\o_$

Dat van die korting is natuurlijk wel makkelijker, maar volgens mij verschilt de korting weer per product. Ga ik idd aan de klant vragen.

donderdag 20 juli 2006 10:38

Acties:

P_de_B

Rekcor schreef op donderdag 20 juli 2006 @ 10:30:
@P_de_B

[...]

Oke. Wanneer wordt het oppassen geblazen? 100.000 rijen? 1.000.000 rijen? Heb zelf tot nu toe alleen nog maar een CMSje gemaakt, en die kwam niet boven de 1000 rijen uit...

Ligt heel erg aan de software, de belasting, de hardware, de sql code, de indexen etc etc. Maar ook over een paar honderduizend rijen zou ik me geen zorgen maken.

Oops! Google Chrome could not find www.rijks%20museum.nl

donderdag 20 juli 2006 10:43

Acties:

Harmen1975

Nog een kleine hint: neem audit-kolommen op in je tabellen.
Altijd handig om (achteraf) te zien wie welk record heeft ingevoerd / gemuteerd.

If you don't succeed at first, redefine succes.

donderdag 20 juli 2006 10:50

Acties:

CH4OS

It's a kind of magic

Salandur schreef op donderdag 20 juli 2006 @ 10:21:
je krijgt natuurlijk ook orders:
order
- id
- klantid
- korting
- datum

met orderregels:
orderregel
- id
- orderid
- productid
- prijs (per stuk)
- aantal

op deze manier heb je een redelijk completer systeem, omdat je nu kan zien wat een klant op een bepaald moment heeft besteld en ook per product wat de klant ervoor heeft betaald (de prijs op dat moment)