[alg] Order(regels): unique ID of regelnummers

[Verwijderd]

Ik hoop dat de topictitel de lading een beetje dekt. Even een simpel voorbeeldje. We hebben 2 tabellen; orders en orderregels. Nu ben ik gewend om deze als volgt te maken:

code:

Order: ID <PK op ID>
Orderregel: ID, OrderID <PK op ID, FK OrderID-->Order.ID>

Beide ID velden zijn auto-incrementent velden

Nu hebben we een discussie met iemand die het als volgt doet:

code:

Order: ID <PK op ID>
Orderregel: OrderID, Regelnummer <PK op OrderID en Regelnummer, FK OrderID-->Order.ID>

Het regelnummer wordt dan bepaald op het moment dat de orderregel toegevoegd wordt. Bij verwijderen van regels kunnen dus gaten ontstaan.

Voor m'n gevoel is de eerste methode 'beter', maar ik krijg het niet voor elkaar dit goed te beargumenteren. Ten eerste; heb ik uberhaupt gelijk? Ten tweede, kan iemand mij uitleggen waarom de ene methode correct is en de andere niet. Of is het echt slechts een kwestie van smaak?

[ Voor 4% gewijzigd door Verwijderd op 14-09-2004 17:02 . Reden: typfoutje ]

[whoami]

Ik doe het altijd op de eerste manier.
Beide manieren zijn correct, en ik denk dat de 2de manier vroeger meer gebruikt werd om zo weinig mogelijk plaats te verbruiken.
Echter, de eerste manier is met de huidige DBMS'en het makkelijkst te implementeren (vind ik), vandaar dat het mijn voorkeur krijgt.

[ Voor 8% gewijzigd door whoami op 14-09-2004 17:04 ]

[kasper_vk]

Mijn voorkeur gaat uit naar een iets andere constructie:
Order: Primary Key (ID)
OrderRegel: Primary Key (Order.ID, Product.ID)
Product: Primary Key(ID)

Lijkt me ook een iets correcter model: met aparte ID's of regelnummers kun je meerdere orderregels krijgen met hetzelfde product, terwijl een orderregel in principe de N-op-N relatie tussen product en order verwezenlijkt.

[FendtVario]

Het implementeren van de 1ste manier is de makkelijkste. Je laat het DBMS het ID bepalen, daar hoef je zelf dus niet voor te zorgen. Bij de 2de manier moet je zelf (of via een stored procedure) steeds op zoek naar het laatste regelnummer en deze ophogen. Dat er vervolgens gaten in vallen als er een regel verwijderd wordt maakt niet zo veel uit.

Ik denk dat ik de 2de manier de kans op fouten vergroot (je moet immers zelf aan de slag), en de 1ste is lekker simpel. Voor mij de eerste manier.

[FendtVario]

kasper_vk schreef op 14 september 2004 @ 17:51:Lijkt me ook een iets correcter model: met aparte ID's of regelnummers kun je meerdere orderregels krijgen met hetzelfde product, terwijl een orderregel in principe de N-op-N relatie tussen product en order verwezenlijkt.

Of je geen orderregels wilt met hetzelfde product nummer hangt er van af. Stel nu dat je een creditorder maakt. Iemand heeft een product afgenomen dat defect is. Op de credit order zet je 1x het defecte product met aantal = -1 en 1x het vervangende product met aantal = 1. Dat gaat niet met jouw opzet.

[GarBaGe]

Ik heb een dergelijke database ook gebouwd...

Mijn orderregel-tabel heeft geen primary key, alleen maar foreign keys (naar order en product)

Er kunnen namelijk meerdere dezelfde producten op 1 order staan. Zeker als je rekening houdt met credit-boeken en evt korting op 2e artikel oid...

De orderregel-tabel wordt altijd benarderd via order-tabel / product-tabel of als kruis-tabel. Een eigen key (primary-key) is in feite NIET nodig voor orderregel-tabel

[kasper_vk]

Dat hangt dus af van je model. Wanneer je inderdaad rekening wilt houden met verschillende soorten orderregels, dan wordt de primary key van de tabel orderregel dus een samengestelde sleutel van Order-ID, product-ID en regelType (o.i.d.). Allen zijn tevens vreemde sleutel, regeltype leg je ook vast als tabel, zodat er geen niet-bestaande regeltypen ingevuld kunnen worden.

Verder: een tabel zonder primaire sleutel is jezelf voor de gek houden en tevens geen gebruik maken van datgene wat het sterkste punt van een relationele database is: het controleren & behouden van z'n eigen (referentiele) integriteit.
Je schrijft zelf al dat je een regel identificeert met de combinatie van o.a. order en product: ok al heb je dat in het gebruikte DBMS (MS Access?) niet gedefinieerd als primaire sleutel, in feite is het je identificatie en dus zou het de PK moeten zijn.
No Offence: maar da's echt les 1 uit de database-leer .
Eventueel aangevuld met (een) andere kandidaadsleutel(s) als je b.v. meerdere typen orderregels wilt.
Zonder primaire sleutel kunnen er, hoe complex je het model ook maakt, meerdere regels gaan ontstaan voor eenzelfde regel (2x een creditorder voor zelfde artikel op zelfde order bv.). Je database is dan niet integer meer.

[Verwijderd]

Dus, even samenvattend... beide methoden zijn correct, maar de eerste is eenvoudiger te implementeren en voorkomt fouten. Hmmm, niet helemaal waar ik op gehoopt had, maar bedankt

[Gomez12]

Vanwege gebruikersgemak zou ik gaan voor optie 2. Het is wel zo makkelijk als iemand met een geprinte in zijn hand jou opbelt en zegt dat er iets op regel 12 staat dat het dan ook bij jou op regel 12 staat ( ongeacht wat er is verwijderd ).

[bRight]

GarBaGe schreef op 14 september 2004 @ 18:05:
Ik heb een dergelijke database ook gebouwd...

Mijn orderregel-tabel heeft geen primary key, alleen maar foreign keys (naar order en product)

Er kunnen namelijk meerdere dezelfde producten op 1 order staan. Zeker als je rekening houdt met credit-boeken en evt korting op 2e artikel oid...

De orderregel-tabel wordt altijd benarderd via order-tabel / product-tabel of als kruis-tabel. Een eigen key (primary-key) is in feite NIET nodig voor orderregel-tabel

Daar ben ik het niet helemaal mee eens..
Als je in later stadium de produkten binnen een order wilt kunnen wijzigen, is het erg handig als je de producten die onder een order vallen kunt identificeren op een uniek (regel)ID.
Wat kasper_vk in een wat langer verhaal ook aangeeft dus

[Verwijderd]

Gomez12 schreef op 15 september 2004 @ 12:03:
Vanwege gebruikersgemak zou ik gaan voor optie 2. Het is wel zo makkelijk als iemand met een geprinte in zijn hand jou opbelt en zegt dat er iets op regel 12 staat dat het dan ook bij jou op regel 12 staat ( ongeacht wat er is verwijderd ).

Die manier van modelleren staat mij dus zo ontzettend tegen (en daarom dus ook optie 2, omdat een dergelijke reden volgens mij achter de voorkeur voor deze optie zit). Dat is iets wat je in je business logica oplost, niet in je abstracte datamodel.

[Canaria]

Ik zou voor de 2e optie kiezen. In dat geval is het zo dat de regelnummers afhankelijk zijn van de orders. Zonder orders, geen regels. En als de order verdwijnt heb je geen loze regelnummers. Daarnaast vind ik het gebruiksvriendelijker om naar een regelnummer te verwijzen door ordernummer.regelnummer ipv alleen regelnummer.
Vergelijk bijvoorbeeld 34287.09 met 287362. De laatste is betekenisloos buiten de db.

[whoami]

Canaria schreef op 15 september 2004 @ 13:39:
Ik zou voor de 2e optie kiezen. In dat geval is het zo dat de regelnummers afhankelijk zijn van de orders. Zonder orders, geen regels. En als de order verdwijnt heb je geen loze regelnummers. Daarnaast vind ik het gebruiksvriendelijker om naar een regelnummer te verwijzen door ordernummer.regelnummer ipv alleen regelnummer.
Vergelijk bijvoorbeeld 34287.09 met 287362. De laatste is betekenisloos buiten de db.

Dat 'Regelnummer' is er eigenlijk enkel voor interne doeleinden voor het DBMS. De gebruiker hoeft dat regelnummer helemaal niet te zien, hij hoeft er zelfs helemaal niets vanaf te weten.