[mySQL] auto-increment bij multiple key

[EmilneM]

Tabel 'klanten' in een MySQL-database ziet er als volgt uit:

KLANTEN

KlantID

BedrijfID

KlantNaam

Een klant hoort bij een bepaald bedrijf en heeft een ID en een naam. Zoals je hierboven ziet zijn KlantID en BedrijfID samen de primary key.

Is het mogelijk om veld KlantID auto-increment te maken kijkend naar BedrijfID? Dus als volgt:

KLANTEN

KlantID	BedrijfID	KlantNaam
1	1	John
2	1	Frits
3	1	Bernd
1	2	Gijsbert
4	1	Martin
2	2	Robert

Ik zou het ook handmatig kunnen doen maar het mooie van 'auto-increment' is dat als ik een record verwijder de key niet meer opnieuw wordt gebruikt, zodat verwijzingen consistent blijven. Bij handmatig is dit niet het geval; als ik het record met de hoogste KlantID verwijder en vervolgens een nieuwe klant aanmaak krijgt deze namelijk hetzelfde KlantID als de zojuist verwijderde klant.

Weet iemand een oplossing?

edit:

Titel vergeten! Kan een mod de titel editten naar '[mySQL] auto-increment bij multiple key'?

[ Voor 5% gewijzigd door EmilneM op 22-12-2004 20:57 ]

[whoami]

Nee, dat is niet mogelijk. (Althans, niet AFAIK in Sql Server, en dus wellicht ook niet in MySQL).

Je zou misschien zelf een nummertje kunnen laten generen dmv een trigger etc..., maar dat wordt niet ondersteunt in MySQL.
Verder vraag ik me af waarom je dat ID zo belangrijk vind, dat het moet nummeren binnen een ander nummer? Een Id is niet meer dan een adminstratief gegeven voor de DB. (Althans dat zou het moeten zijn, ik ben iig niet zo'n voorstander van 'natural keys' (-> id's waar een 'waarde' aan gegeven wordt.)

[EmilneM]

whoami schreef op woensdag 22 december 2004 @ 21:07:
Nee, dat is niet mogelijk. (Althans, niet AFAIK in Sql Server, en dus wellicht ook niet in MySQL).

Je zou misschien zelf een nummertje kunnen laten generen dmv een trigger etc..., maar dat wordt niet ondersteunt in MySQL.
Verder vraag ik me af waarom je dat ID zo belangrijk vind, dat het moet nummeren binnen een ander nummer? Een Id is niet meer dan een adminstratief gegeven voor de DB. (Althans dat zou het moeten zijn, ik ben iig niet zo'n voorstander van 'natural keys' (-> id's waar een 'waarde' aan gegeven wordt.)

Een klantID moet zichtbaar kunnen zijn op scherm of factuur en de gebruiker wil dat klantnummering voor elk bedrijf apart gebeurt.

[P_de_B]

Zoals whoami al zegt, dit gaat je niet lukken met standaard database functies van mySQL. In script zou het wel lukken maar dan zit je weer met allerlei concurrency problemen. Het is in mijn ogen ook niet aan te raden dit zo te doen, er zit geen voordeel aan, alleen maar nadelen.

* P_de_B is ook voorstander van 'domme' keys


EDIT:

kun je de gebruiker er niet van overtuigen dat het weinig zin heeft? Wat ga je bijvoorbeeld doen als er een klant verdwijnt? Ga je dan alles hernummeren, incl. foreign keys? Vraag hem eens naar het voordeel.

offtopic:
een titelchange kun je aanvragen met het 'handje'boven in het scherm

[ Voor 25% gewijzigd door P_de_B op 22-12-2004 21:17 ]

[curry684]

Wtf is het nut van een dubbele primary key in dit geval?

Ik mag toch hopen dat bedrijfID een foreign key is, anders snap ik weinig van je datamodel...

[EmilneM]

curry684 schreef op woensdag 22 december 2004 @ 21:16:
Wtf is het nut van een dubbele primary key in dit geval?

Ik mag toch hopen dat bedrijfID een foreign key is, anders snap ik weinig van je datamodel...

BedrijfID is idd foreign key

kun je de gebruiker er niet van overtuigen dat het weinig zin heeft? Wat ga je bijvoorbeeld doen als er een klant verdwijnt? Ga je dan alles hernummeren, incl. foreign keys? Vraag hem eens naar het voordeel.

Juist niet hernummeren. Nieuwe klanten mogen liefst juist geen ID's van een verwijderde klant aannemen omdat er nog orders in het systeem kunnen staan met oude klantID's. Data wordt dan inconsistent.

[ Voor 44% gewijzigd door EmilneM op 22-12-2004 21:25 ]

[P_de_B]

EmilneM schreef op woensdag 22 december 2004 @ 21:20:
[...]


BedrijfID is idd foreign key


[...]

Juist niet hernummeren. Nieuwe klanten mogen liefst juist geen ID's van een verwijderde klant aannemen omdat er nog orders in het systeem kunnen staan met oude klantID's. Data wordt dan inconsistent.

Wat heb je dan voor reden om opvolgende nummers binnen een bedrijf te hebben? Gewoon een oplopende key voor klanten gebruiken is echt de beste oplossing. Na verloop van tijd klopt het toch niet meer.

[curry684]

EmilneM schreef op woensdag 22 december 2004 @ 21:20:
[...]

BedrijfID is idd foreign key

Dus hij is zowel foreign als primary? Han-dig

[...]

Juist niet hernummeren. Nieuwe klanten mogen liefst juist geen ID's van een verwijderde klant aannemen omdat er nog orders in het systeem kunnen staan met oude klantID's. Data wordt dan inconsistent.

Dat kan niet als jij gewoon een goede database met referential integrity bouwt: dan kun je namelijk geen klanten deleten zolang er nog orders aan hangen. Dat MySQL het standaard toestaat is enkel des te meer nagel aan de doodskist van het kreng dat je het niet voor serieuze systemen moet gebruiken (tip: zoek eens op innoDB). De correcte manier om zo'n klant 'af te schrijven' is in ieder geval een 'Deleted' flag in de tabel opnemen. Daarnaast hoort het klantID een meaningless nummertje te zijn, waarvoor je logischerwijs een auto-increment veld op 1 veld neemt wat dan je primary key is.

Ik zie nogmaals het nut niet van een dubbele primary key, eigenlijk in het algemeen niet en in dit geval al helemaal niet.

[kvdveer]

curry684 schreef op woensdag 22 december 2004 @ 21:29:
Ik zie nogmaals het nut niet van een dubbele primary key, eigenlijk in het algemeen niet en in dit geval al helemaal niet.

Een dubbele primary key kan wel nuttig zijn hoor, alleen in dit geval niet. Het lijkt er op dat de TS geen kaas heeft gegeven van normaliseren, en vragen van zijn klant verwart met techtnische eisen. Als de klant een klantnummer toe wil kennen, prima. Maar dat maakt het nog geen primary key, en zeker geen autoincrement.

offtopic:
Een dubbele primary key is nuttig als je key uit twee delen bestaat die individueel niet uniek zijn. Koppeltabellen hebben nog wel eens dubbele primary keys (die overigens ook beide foreign keys zijn).
Stel je de database voor: studenten/docenten. Per combinatie student-docent wil je iets registreren, het aantal ruzies bijvoorbeeld. (stom voorbeeld, ja). Je krijgt dan iets als:
Student(id,naam,geslacht,...)
Docent(id,naam,kapsel,...)
koppel_student_docent(student_id*,docent_id*,ruzie,...)
Je kan aan koppel_student_docent wel een autoincrement toevoegen, maar deze heeft dan toch geen nut.