[Database] ID's, wat is verstandig?

[Verwijderd]

Een web applicatie, gemaakt in php met mysql database waarin producten en klanten/gebruikers in beheerd moeten worden. Wat is daar nou verstandig om aan ID toe te kennen?
Auto_increment is wel handig maar ik heb zo mijn twijfels, ik weet ook niet precies waarom maar bij de grotere webshops zie ik ook geen enige regelmaat in id's als je soms naar die url's kijkt.

[gorgi_19]

Waarom zou je geen auto increments gebruiken?

[Lentje]

Waarom zou je geen auto_increment gebruiken? Is de meest logische manier imo.

Je kan een unieke string genereren maar daar heb je theoretisch de kans bij dat je een 2e keer dezelfde string maakt.

[Rac-On]

auto_increment is ook de manier om je database en realties consistent te houden als je een keer een product oid verwijderd (omdat het id niet opnieuw wordt uitgegeven).
Als je zelf een key genereerd heb je, zelf als je een unique key required zet, de kans dat je de key van een eerder aangemaakt en verwijderd product opnieuw gebruikt, en er verolgens ongewenste koppelingen op id nog bestaan

[NMe]

Verwijderd schreef op dinsdag 14 december 2004 @ 18:31:
Auto_increment is wel handig maar ik heb zo mijn twijfels, ik weet ook niet precies waarom maar bij de grotere webshops zie ik ook geen enige regelmaat in id's als je soms naar die url's kijkt.

En wat laat jou denken dat gekke getallen in URLs per se user ID's moeten zijn? Misschien is het een sessie ID, en staat het echte user ID wel in die sessie.

Om kort te gaan, gebruik gewoon auto increment velden voor ID's.

[Verwijderd]

Gebruik in elk geval nooit een select max(id) oid, daar kom je geheid mee in de problemen.

Voor klanten is het niet handig om ID's rechtstreeks in je URL's te gebruiken, beter is daar een hash van bv. ID met naam oid. Dit is omdat anders derden je hele database leeg zouden kunnen trekken door gewoon de ID's na te lopen, is dus meer een security issue dan een technisch issue.

Voor de ID's in de tabellen zou ik gewoon een autoincrement gebruiken, ik ga er daarbij van uit dat MySQL dat goed implementeerd en niet zoals bv. Access, waarin dat vragen om problemen is.

[Loesje]

Offtopic, maar interessant: Hoe gaat Access daarmee de mist in, dan?

[drm]

Loesje:
Offtopic, maar interessant: Hoe gaat Access daarmee de mist in, dan?

User A	User B
Wat is het hoogste id +1?	Wat is het hoogste id +1?
Access: Nou, da's 169 knul!	Access: hej, jij ook? Nou, 169 dus!
Ok, insert maar dan, met ID 169	Ok, insert maar dan, met ID 169
Gelukt woei!	Sorry, 169 is al in gebruik, is net weggestolen

Zo ongeveer

edit:

Als je het met MAX doet gaat het, zonder expliciete locking, volgens mij in de meeste dbms'en wel fout.

[ Voor 13% gewijzigd door drm op 14-12-2004 19:00 ]

[Verwijderd]

Drm: het ging hier over autoinc.

Hoe access er precies de mis mee ingaat, kan ik je niet vertellen. Heb immers de code van Access niet.

In mijn ervaring echter gaat Access er vroeger of later wel de mist mee in, in de vorm van dat een ID uitgegeven wordt, wat al uitgegeven was bv. Ik heb dit in het verleden wel eens getest door domweg 3 computers continu records te laten aanmaken in één database, en daarbij liep hij eigenlijk altijd binnen een uur vast.

[Flard]

drm schreef op dinsdag 14 december 2004 @ 18:58:
[...]

User A	User B
Wat is het hoogste id +1?	Wat is het hoogste id +1?
Access: Nou, da's 169 knul!	Access: hej, jij ook? Nou, 169 dus!
Ok, insert maar dan, met ID 169	Ok, insert maar dan, met ID 169
Gelukt woei!	Sorry, 169 is al in gebruik, is net weggestolen

Zo ongeveer

edit:

Als je het met MAX doet gaat het, zonder expliciete locking, volgens mij in de meeste dbms'en wel fout.

Volgens mij gaat dat ook gewoon fout bij mySQL hoor, als hij dat niet zou doen krijg je dus twee dingen met ID 169 in je db

Verder geef ik het (autonummering) ID niet mee bij een INSERT-statement, dat wordt immers automatisch door Access ingevuld.

[drm]

Flard:
Volgens mij gaat dat ook gewoon fout bij mySQL hoor, als hij dat niet zou doen krijg je dus twee dingen met ID 169 in je db

euh

Als je het met MAX doet gaat het, zonder expliciete locking, volgens mij in de meeste dbms'en wel fout.

Verder geef ik het (autonummering) ID niet mee bij een INSERT-statement, dat wordt immers automatisch door Access ingevuld.

Da's terecht, want daar is het ook autonummering voor

---

De Generaal: Drm: het ging hier over autoinc.

dan heb ik niks gezegd.

edit:

Dat wil zeggen: ik weet wel dat access niet al te goed bekend staat als het gaat om concurrency problemen, dus 't kan best zijn dat iets dergelijks wel aan de hand is.

Het heruitgeven van ID's zou ook geen problemen mogen zijn, gezien referentiele integriteit daar niet van af hangt, maar van de vraag of een ID uniek is of niet, en of de verwijzingen naar ID's wel correct zijn, etcetera. Een uniek id is een uniek id, hergebruikt of niet.

[ Voor 28% gewijzigd door drm op 14-12-2004 19:17 ]

[Verwijderd]

Meestal zijn Auto Inc velden goed genoeg voor unieke keys. Toch zijn er wel een paar zaken waar je rekening mee moet houden

- Een autoinc veld wordt door de database gegenereerd. Je client (of php script) weet dus niet automatisch welk ID er gegenereerd is. Als je dat ID nog verder wilt gebruiken moet je het gegenereerde ID weer zien te achterhalen voordat je verder gaat. Dit kan lastig zijn. Het is onjuist om er vanuit gegaan dat het laast gegenereerde ID jou ID was. Ook al vraag je het gelijk na de insert op. Het kan van een andere gebruiker zijn, die ongeveer gelijktijdig een record geinsert heeft. Goede databases hebben hier een oplossing voor, maar ook daarmee moet je oppassen. Zo is de @@Identity methode van MS SQL niet geschikt. Maar de current_Identity methode weer wel.
- Heb je meerdere databases (bv 1 in de USA, 1 in Europa en 1 in Asie) die je zo nu en dan moet mergen kunnen ze (nee, zullen ze) dezelfde autoinc waarden genereren voor verschillende records. Je kan dan gebruik maken van zaken als GUIDs om toch unieke records te genereren. GUIDs hebben echter zelf ook nadelen. Zo zijn ze random en staan ze dus niet op alfabetische volgorde in de DB.
- Werk je met hele grote databases, kun je in de problemen komen dat je auto Inc veld gaat overlopen (nu is dat bij 64 bits velden al weer een stuk minder een probleem dan bij 32 bits velden, maar goed) Dan krijg je na verloop van tijd je oude waarden weer terug.

Dus normaal gesproken kun je prima vertrouwen op auto inc velden mits je met deze drie zaken kan leven. Zo niet, kun je aan GUIDs of Generators gaan denken.

[Verwijderd]

drm schreef op dinsdag 14 december 2004 @ 19:15:
dan heb ik niks gezegd.

edit:

Dat wil zeggen: ik weet wel dat access niet al te goed bekend staat als het gaat om concurrency problemen, dus 't kan best zijn dat iets dergelijks wel aan de hand is.

Bingo

[Tom-my]

Zie niet wat er mis is aan unique identifiers, je kijkt bij het koppelen van verzamelingen naar gelijke waarden in beide verzamelingen. Doet er niet toe of die van een autoinc komt.

[ Voor 4% gewijzigd door Tom-my op 14-12-2004 22:15 . Reden: oeps jan klaasje was me al voor ]

[Verwijderd]

Ik denk dat het verstandig is om twee zaken uit elkaar te halen.
* Het doel van een id-veld is om unieke inhoud mee aan te duiden. Zo'n veld is meestal gekoppeld aan een UNIQUE CONSTRAINT.
* Dat sommige databases hier meteen een autonummering-functie/sortering bij voegen dat is een andere vraag.

Interbase, Firebird (en ik dacht ook PostGreSQL) hebben hier beter over nagedacht. Hierbij kun je van te voren een uniek id opvragen voor gebruik in je applicatie en eventueel later weer gebruiken om een record toe te voegen, updaten, ofzo.

[Erkens]

Verwijderd schreef op dinsdag 14 december 2004 @ 19:16:
- Een autoinc veld wordt door de database gegenereerd. Je client (of php script) weet dus niet automatisch welk ID er gegenereerd is. Als je dat ID nog verder wilt gebruiken moet je het gegenereerde ID weer zien te achterhalen voordat je verder gaat. Dit kan lastig zijn. Het is onjuist om er vanuit gegaan dat het laast gegenereerde ID jou ID was. Ook al vraag je het gelijk na de insert op. Het kan van een andere gebruiker zijn, die ongeveer gelijktijdig een record geinsert heeft. Goede databases hebben hier een oplossing voor, maar ook daarmee moet je oppassen. Zo is de @@Identity methode van MS SQL niet geschikt. Maar de current_Identity methode weer wel.

De mysql functie LAST_INSERT_ID() geeft de ID terug die er door dezelfde database connectie het laatst is ge-insert, dus een SELECT LAST_INSERT_ID() is voldoende om _echt_ die ID op te vragen, hoewel dat een probleem kan zijn met bepaalde implementaties, immers als je een Database connectie shared voor meedere gebruikers gelijktijdig, dan heb je idd dat probleem

[Woy]

Verwijderd schreef op dinsdag 14 december 2004 @ 19:16:
Zo is de @@Identity methode van MS SQL niet geschikt. Maar de current_Identity methode weer wel.

Mag ik vragen wat er mis is met de @@identity methode in MS SQL? Ik dacht dat die ook gewoon het laatst identity van een geselecteer/geupdate/geinsert record van de huidige connectie opleverde, dan zie ik niet wat het probleem is om deze te gebruiken.

[P_de_B]

rwb schreef op woensdag 15 december 2004 @ 09:52:
[...]


Mag ik vragen wat er mis is met de @@identity methode in MS SQL? Ik dacht dat die ook gewoon het laatst identity van een geselecteer/geupdate/geinsert record van de huidige connectie opleverde, dan zie ik niet wat het probleem is om deze te gebruiken.

Die kan bij het gebruik van triggers een onjuiste ID teruggeven. Je kunt dan beter SCOPE_IDENTITY() gebruiken. Als er geen triggers gebruikt worden is @@IDENTITY prima.

[Verwijderd]

Lees een goed boek over database normalisatie, kan je vast veel aan hebben denk ik zo.

[LauPro]

Ik gebruik in mijn webapplicaties altijd de ID's van de database intern en voor een id dat publiekelijk zichtbaar is genereer ik een unieke 8-alfanumerieke code (zonder klinkers en de 0.) Hiermee voorkom je dat mensen of dingen een 'nummertje' worden (en voorkom je conbinaties als 1337, 666, 538, 112 etc.) Daarnaast is het vrijwel onmogelijk (zoals eerder gezegd) om hele ranges te 'leechen'.

[Woy]

P_de_B schreef op woensdag 15 december 2004 @ 09:56:
[...]


Die kan bij het gebruik van triggers een onjuiste ID teruggeven. Je kunt dan beter SCOPE_IDENTITY() gebruiken. Als er geen triggers gebruikt worden is @@IDENTITY prima.

Ah jah daar had ik natuurlijk niet aan gedacht. Dan is SCOPE_IDENTITY() inderdaad beter, maar dan moet je wel gebruik maken van Stored Procedures of je Select Scope_Identity in dezelfde batch uitvoeren ( Wat natuurlijk ook logisch is )

[Erkens]

LauPro schreef op woensdag 15 december 2004 @ 10:05:
Ik gebruik in mijn webapplicaties altijd de ID's van de database intern en voor een id dat publiekelijk zichtbaar is genereer ik een unieke 8-alfanumerieke code (zonder klinkers en de 0.) Hiermee voorkom je dat mensen of dingen een 'nummertje' worden (en voorkom je conbinaties als 1337, 666, 538, 112 etc.) Daarnaast is het vrijwel onmogelijk (zoals eerder gezegd) om hele ranges te 'leechen'.

Dus jij hebt per record een extra uniek veld? Waarom gebruik je die dan niet meteen ook als primairy key? maw, wat is het nu van twee unieke velden in dit verhaal? Je zou namelijk ook gewoon een nieuwe "unieke" key kunnen genereren aan de hand van de echte key als leechen echt een probleem is imo

[Woy]

Erkens schreef op woensdag 15 december 2004 @ 10:18:
[...]

Dus jij hebt per record een extra uniek veld? Waarom gebruik je die dan niet meteen ook als primairy key? maw, wat is het nu van twee unieke velden in dit verhaal? Je zou namelijk ook gewoon een nieuwe "unieke" key kunnen genereren aan de hand van de echte key als leechen echt een probleem is imo

Het leechen van je database is denk meestal ook gewoon een probleem van je applicatie. Als je gegevens hebt die klant gebonden zijn moet je bij het tonen van de gegevens ook gewoon controlleren of die gegevens wel bij de juiste user horen. Als dat het geval is dan haalt het meestal niet zoveel uit dat iemand door het veranderen van een id andere gegevens op kan vragen. Dat zou hij anders ook kunnen door in de applicatie een ander item te selecteren. Bij bijvoorbeeld een telefoonboek is dat natuurlijk weer niet het geval omdat je niet wilt dat iemand je database kan kopieren om zelf een telefoonboek te beginnen. Maar bij de applicaties die ik altijd maak zijn het meestal gegevens die toch betrekking hebben op de gebruiker die ingelogd is en dus haalt het niet uit als hij al zijn gegevens uit kan lezen op een andere manier als de daarvoor bedoelde.

[LauPro]

Matchen op een getal ipv een string is een stuk sneller. Vandaar 2 ID's. Ook meteen goed gescheiden (intern en publiekelijk.)

[Erkens]

LauPro schreef op woensdag 15 december 2004 @ 10:23:
Matchen op een getal ipv een string is een stuk sneller. Vandaar 2 ID's. Ook meteen goed gescheiden (intern en publiekelijk.)

maar vervolgens moet je wel een extra query doen om toch die ID op te halen dus dat argument is _niks_ waard

[pierre-oord]

LauPro schreef op woensdag 15 december 2004 @ 10:05:
Ik gebruik in mijn webapplicaties altijd de ID's van de database intern en voor een id dat publiekelijk zichtbaar is genereer ik een unieke 8-alfanumerieke code (zonder klinkers en de 0.) Hiermee voorkom je dat mensen of dingen een 'nummertje' worden (en voorkom je conbinaties als 1337, 666, 538, 112 etc.) Daarnaast is het vrijwel onmogelijk (zoals eerder gezegd) om hele ranges te 'leechen'.

Hoe bedoel je dit precies?

Die extra publieke rij, is dat dan een ID die met een code afhankelijk is van het userid? Bijvoorbeeld (userid * 8 + 27)? Zodat als iemand dan voor user 100 iets stuurt, hij "827" opgeeft, waarna je script zegt (827 - 27) / 8 = 100 ?

Op dit moment ben ik af en toe bezig aan een site met een hoop gegevens, op te vragen door iedere gebruiker, maar waarvan ik idd niet wil dat ze worden opgehaald door een of ander script.

[Verwijderd]

LauPro schreef op woensdag 15 december 2004 @ 10:23:
Matchen op een getal ipv een string is een stuk sneller. Vandaar 2 ID's. Ook meteen goed gescheiden (intern en publiekelijk.)

Volgens mij valt dat reuze mee. Een goede database doet daar echt niet moeilijk over. Ook het voordeel van de interne en publieke scheiding zie ik niet zo. Als je een unieke id hebt die extern voldoet aan je wensen waarom zou je dan nog een ander (intern) id gebruiken? Je maakt het jezelf alleen maar moeilijker.
Volgens mij kan je beter zorgen dat je datamodel goed doordacht en logisch in elkaar zit dan dat je "truukjes" uithaald. Heb je veel meer voordeel van (vooral later bij onderhoud en uitbreiding).

[ Voor 3% gewijzigd door Verwijderd op 15-12-2004 10:58 ]

[FendtVario]

Erkens schreef op woensdag 15 december 2004 @ 10:18:
Dus jij hebt per record een extra uniek veld? Waarom gebruik je die dan niet meteen ook als primairy key? maw, wat is het nu van twee unieke velden in dit verhaal? Je zou namelijk ook gewoon een nieuwe "unieke" key kunnen genereren aan de hand van de echte key als leechen echt een probleem is imo

Het is makkelijker om één veld te hebben als primary key dan twee. Dit omdat een vreemde sleutel in een andere tabel altijd de primary key van de gekoppelde tabel is. Stel dat je klanten in een systeem zet en daarbij klantnummer als primary key gebruikt. Het zal niet vaak voorkomen maar stel dat het nodig is het klantnummer te veranderen, dan moet je in alle gekoppelde tabellen het klantID veranderen. Gebruik je een auto increment als ID kun je het klantnummer best veranderen zonder dat bijv. orders of acties van die klant geupdate hoeven worden.

Daarnaast kun je natuurlijk best het veld KlantNumer in een tabel uniek maken, lijkt mij niet zo handig als je twee klanten hebt met eenzelfde nummer. Een uniek veld in je tabel is niet noodzakelijk ook direct de primary key.

Pas las ik ergens dat je het beste een betekenisloos veld als sleutel kan nemen, bijv. een auto_increment of GUID. Dit voorkomt lastige updates in de relaties tussen tabellen. (bron: Pragmatisch modeleren met UML 2.0, deel 8, blz 351)

[Erkens]

FendtVario schreef op woensdag 15 december 2004 @ 11:38:
Het is makkelijker om één veld te hebben als primary key dan twee. Dit omdat een vreemde sleutel in een andere tabel altijd de primary key van de gekoppelde tabel is. Stel dat je klanten in een systeem zet en daarbij klantnummer als primary key gebruikt. Het zal niet vaak voorkomen maar stel dat het nodig is het klantnummer te veranderen, dan moet je in alle gekoppelde tabellen het klantID veranderen. Gebruik je een auto increment als ID kun je het klantnummer best veranderen zonder dat bijv. orders of acties van die klant geupdate hoeven worden.

Daarnaast kun je natuurlijk best het veld KlantNumer in een tabel uniek maken, lijkt mij niet zo handig als je twee klanten hebt met eenzelfde nummer. Een uniek veld in je tabel is niet noodzakelijk ook direct de primary key.

ik zeg ook nergens dat je meerdere velden in je primary key moet hebben.
Uiteraard kan je prima een klantID niet als pkey gebruiken op het moment dat het vaak voorkomt dat die kan veranderen (hoewel dat denk ik geen goed voorbeeld is, een klantID veranderd eigenlijk nooit, alleen door een menselijke fout ) maar dan nog kan een relationele database die keys makkelijk zelf aanpassen.

Pas las ik ergens dat je het beste een betekenisloos veld als sleutel kan nemen, bijv. een auto_increment of GUID.

Goed nu je dit zegt geef je meteen aan dat je niet goed gelezen hebt
Het ging hier al om een nietszeggende key (auto_increment) en daarnaast nog een andere nietszeggend veld wat gebruikt werd ter identificatie van het betreffende record

[FendtVario]

Erkens schreef op woensdag 15 december 2004 @ 11:44:
ik zeg ook nergens dat je meerdere velden in je primary key moet hebben.
Uiteraard kan je prima een klantID niet als pkey gebruiken op het moment dat het vaak voorkomt dat die kan veranderen (hoewel dat denk ik geen goed voorbeeld is, een klantID veranderd eigenlijk nooit, alleen door een menselijke fout ) maar dan nog kan een relationele database die keys makkelijk zelf aanpassen.

Tuurlijk kan een relationeel dbms dit aanpassen, maar ik vraag me af in hoeverre je daarmee de schaalbaarheid van je systeem beperkt. In een database met een paar honderd tabellen is het natuurlijk niet handig om overal de sleutel te moeten updaten (ook al zal een klantID niet in elke tabel voorkomen). Gaat dat niet heel lang duren of komt je dan niet in de problemen met gegevens die ander gebruikers op dat moment aan het wijzigen zijn die gekoppeld zijn aan die (in dit geval) klant?

Goed nu je dit zegt geef je meteen aan dat je niet goed gelezen hebt
Het ging hier al om een nietszeggende key (auto_increment) en daarnaast nog een andere nietszeggend veld wat gebruikt werd ter identificatie van het betreffende record

De eerste vraag in dit topic is of het verstandig is om ID's toe te kennen aan klanten/gebruikers. Antwoord: ja, is verstandig. Ik had er alleen nog nooit op die manier naar gekeken dat een ID een betekenisloze waarde is. Vandaar die toevoeging.

[LauPro]

Erkens schreef op woensdag 15 december 2004 @ 10:32:
[...]
maar vervolgens moet je wel een extra query doen om toch die ID op te halen dus dat argument is _niks_ waard

Dat valt wel mee, vaak zijn er meer velden nodig als naam, aanmaaktijd etc. Daarnaast kan je hiermee een totaal andere rij aan een URL koppelen. Dat kan wel eens nodig zijn om te voorkomen dat er geen 404 ontstaat (als een andere rij is verwijderd krijg je dat ID niet zomaar weer terug.)

Het belangrijkste argument is trouwens dat die tweede ID uniek is voor alle tabellen. Met 1 ID kan je dus 1 rij uit een database halen, maakt niet uit in welke tabel die zit.

[Erkens]

FendtVario schreef op woensdag 15 december 2004 @ 12:07:
[...]

Tuurlijk kan een relationeel dbms dit aanpassen, maar ik vraag me af in hoeverre je daarmee de schaalbaarheid van je systeem beperkt. In een database met een paar honderd tabellen is het natuurlijk niet handig om overal de sleutel te moeten updaten (ook al zal een klantID niet in elke tabel voorkomen). Gaat dat niet heel lang duren of komt je dan niet in de problemen met gegevens die ander gebruikers op dat moment aan het wijzigen zijn die gekoppeld zijn aan die (in dit geval) klant?

snelheid maakt in zo'n geval weinig uit, immers zo'n update doe je niet erg vaak lijkt me
Overigens heb je ook locking mogelijkheden zodat andere gebruikers niks kunnen veranderen als jij bezig bent

[-FoX-]

Ik weet niet of het écht verstandig is? Maar een rijksregisternummer oid kan je ook best als PK gebruiken, omdat deze toch altijd uniek horen te zijn

[Zoijar]

Erkens schreef op dinsdag 14 december 2004 @ 23:57:
De mysql functie LAST_INSERT_ID() geeft de ID terug die er door dezelfde database connectie het laatst is ge-insert, dus een SELECT LAST_INSERT_ID() is voldoende om _echt_ die ID op te vragen, hoewel dat een probleem kan zijn met bepaalde implementaties, immers als je een Database connectie shared voor meedere gebruikers gelijktijdig, dan heb je idd dat probleem

Volgens mij geen probleem; ik dacht dat mysql kijkt naar welke link het request vandaan kwam, en wat die link het laatste heeft geinsert, los van wat een andere link in de tussentijd misschien gedaan zou kunnen hebben.

(Overigens kom je met een select max ook niet in de problemen, als je je tabel gewoon netjes even locked. Dus "lock rw, select max, insert, unlock rw", hij moet ook wel read locked worden, anders zouden twee threads hetzelfde max kunnen lezen. Je kan natuurlijk ook bij een dubbele insert id, de error afvangen en het opnieuw proberen, door weer een max te selecten. Punt daarvan is een eventuele deadlock...niet netjes)

[ Voor 24% gewijzigd door Zoijar op 15-12-2004 13:22 ]

[Verwijderd]

Verwijderd schreef op dinsdag 14 december 2004 @ 18:31:
Een web applicatie, gemaakt in php met mysql database waarin producten en klanten/gebruikers in beheerd moeten worden. Wat is daar nou verstandig om aan ID toe te kennen?

Over primary keys zijn de geleerden 't volgens mij nog steeds niet eens...
In dit geval zou ik kiezen voor AutoIncrementing, Identity of een generator, maar er zijn een hoop situaties waarbij een samengestelde primary key prettiger werkt.

Neem bv. een reserveringensysteem voor bowlingbanen.
Wanneer je bij de reserveringen een AutoIncrementing primary key gebruikt, zul je nooit conflicten krijgen, maar wanneer je als PK bijv. <datum>,<starttijd>,<baannummer> gebruikt, helpt de database je om te voorkomen dat er dubbele reserveringen optreden.
Bij een AutoInc veld leg je die validatie helemaal aan de client kant. Leuk wanneer je zelf de enige applicatie bent die die database benadert, maar wanneer er meer applicaties/webservices/etc. in die DB roeren, is 't wel fijn dat de database zelf ook nog een stukje validatie doet.

[Erkens]

Zoijar schreef op woensdag 15 december 2004 @ 13:18:
[...]

Volgens mij geen probleem; ik dacht dat mysql kijkt naar welke link het request vandaan kwam, en wat die link het laatste heeft geinsert, los van wat een andere link in de tussentijd misschien gedaan zou kunnen hebben.

dat is toch wat ik zei

[Zoijar]

Erkens schreef op woensdag 15 december 2004 @ 14:49:
dat is toch wat ik zei

Verkeerd gelezen... zag dat je het over een probleem met meerdere gebruikers had oid...sorry.

[FendtVario]

Verwijderd schreef op woensdag 15 december 2004 @ 14:46:
[...]

Over primary keys zijn de geleerden 't volgens mij nog steeds niet eens...
In dit geval zou ik kiezen voor AutoIncrementing, Identity of een generator, maar er zijn een hoop situaties waarbij een samengestelde primary key prettiger werkt.

Neem bv. een reserveringensysteem voor bowlingbanen.
Wanneer je bij de reserveringen een AutoIncrementing primary key gebruikt, zul je nooit conflicten krijgen, maar wanneer je als PK bijv. <datum>,<starttijd>,<baannummer> gebruikt, helpt de database je om te voorkomen dat er dubbele reserveringen optreden.
Bij een AutoInc veld leg je die validatie helemaal aan de client kant. Leuk wanneer je zelf de enige applicatie bent die die database benadert, maar wanneer er meer applicaties/webservices/etc. in die DB roeren, is 't wel fijn dat de database zelf ook nog een stukje validatie doet.

Je kan best voor die reserveringen een ID gebruiken. Naast de primary key maak je dan een index die uniek moet zijn. Mocht je de reservering dan ergens aan willen kopppelen hoef je niet 3 velden op te nemen maar 1. Dan ligt de validatie toch nog bij de database en niet bij de client.

Ik zou ook andere velden nemen om een reservering uniek te maken, of zet je de reservering voor elke minuut (of seconde) in de db?
15-12-2004 15:41 baan 1 familie Jansen
15-12-2004 15:42 baan 1 familie de Groot

[P_de_B]

Verwijderd schreef op woensdag 15 december 2004 @ 14:46:
[...]

Over primary keys zijn de geleerden 't volgens mij nog steeds niet eens...
In dit geval zou ik kiezen voor AutoIncrementing, Identity of een generator, maar er zijn een hoop situaties waarbij een samengestelde primary key prettiger werkt.

Neem bv. een reserveringensysteem voor bowlingbanen.
Wanneer je bij de reserveringen een AutoIncrementing primary key gebruikt, zul je nooit conflicten krijgen, maar wanneer je als PK bijv. <datum>,<starttijd>,<baannummer> gebruikt, helpt de database je om te voorkomen dat er dubbele reserveringen optreden.
Bij een AutoInc veld leg je die validatie helemaal aan de client kant. Leuk wanneer je zelf de enige applicatie bent die die database benadert, maar wanneer er meer applicaties/webservices/etc. in die DB roeren, is 't wel fijn dat de database zelf ook nog een stukje validatie doet.

In mijn ogen is een PK bedoeld om een record uniek te identificeren. Je moet hier geen verdere business logica in proberen te stoppen. Als je andere validatie op je database wilt toepassen moet je dat met constraints doen, niet in de PK

[Woy]

Verwijderd schreef op woensdag 15 december 2004 @ 14:46:
[...]

Over primary keys zijn de geleerden 't volgens mij nog steeds niet eens...
In dit geval zou ik kiezen voor AutoIncrementing, Identity of een generator, maar er zijn een hoop situaties waarbij een samengestelde primary key prettiger werkt.

Neem bv. een reserveringensysteem voor bowlingbanen.
Wanneer je bij de reserveringen een AutoIncrementing primary key gebruikt, zul je nooit conflicten krijgen, maar wanneer je als PK bijv. <datum>,<starttijd>,<baannummer> gebruikt, helpt de database je om te voorkomen dat er dubbele reserveringen optreden.
Bij een AutoInc veld leg je die validatie helemaal aan de client kant. Leuk wanneer je zelf de enige applicatie bent die die database benadert, maar wanneer er meer applicaties/webservices/etc. in die DB roeren, is 't wel fijn dat de database zelf ook nog een stukje validatie doet.

Maar dan heb je nog steeds het probleem dat je een bowling baan meestal een bepaalde periode verhuurt ( b.v. tussen 10:00 en 11:30 ) dan kan je best nog een record toevoegen wat de baan van 10:30 tot 12:00 verhuurt. Dit soort dingen kan je niet echt makkelijk vastleggen in je database en horen ook in je applicatie.

[Verwijderd]

Zoijar schreef op woensdag 15 december 2004 @ 13:18:
[...]
(Overigens kom je met een select max ook niet in de problemen, als je je tabel gewoon netjes even locked. Dus "lock rw, select max, insert, unlock rw", hij moet ook wel read locked worden, anders zouden twee threads hetzelfde max kunnen lezen. Je kan natuurlijk ook bij een dubbele insert id, de error afvangen en het opnieuw proberen, door weer een max te selecten. Punt daarvan is een eventuele deadlock...niet netjes)

Een table lock om een record te inserten? Hoeveel gebruikers wil jij ondersteunen? 2?
Dit is dus gewoon not done!