[MySQL] Waarde 'id' achterhalen

[Verwijderd]

Als je in je tabel als primaire waarde 'id' hebt die als auto_increment staat ingesteld heb je geen controle over de waarde die dit veld krijgt. Als ik in deze tabel een rij invoeg is voor mij dus niet bekend welke waarde deze gaat aannemen, en dat wil ik dus juist wel weten. Een mogelijkheid is om een SELECT query te maken met een WHERE met dezelfde waardes van het invoegen, maar dit vind ik iets omslachtig.
Mijn vraag is dus of het mogelijk is op een simpelere manier de waarde van dit auto_increment veld te achterhalen.

[Verwijderd]

Jazeker. Even zoeken dan heb je het zo gevonden. Als je even vertelt van welke taal je gebruik maakt dan kunnen wij je ook helpen.

[ Voor 48% gewijzigd door Verwijderd op 31-12-2004 14:05 . Reden: spelling error ]

[StevenK]

Je had natuurlijk ook google eens kunnen bezoeken ? http://www.google.nl/sear...&q=mysql+auto%5Fincrement

D'r is klaarblijkelijk een speciale functie in mysql waarmee je de laatste ID weer ophaalt, net zoals een mysql api en ik vermoed dat php hier dan vast ook wel weer een mooie functie omheen heeft geknoopt: http://nl.php.net/mysql_insert_id

[BasieP]

het probleem is alleen dat wanneer jij met meerdere users in 1 database werkt, je wel eens problemen kan krijgen
user 1 insert iets
user 2 insert iets
user 1 vraagt op, en krijgt dus de id van user 2

bekent probleem, maar voor jouw denk ik niet van toepassing. Trouwens is een nog betere oplossing natuurlijk, het maken van een primairy key over velden die je gebruikt bij je invoer, ipv een 'id' veld te gebruiken
op deze manier heb je dus sowieso geen auto increment, en heb je altijd de primairy key direct te pakken. alleen dit is dan weer niet altijd mogelijk, of zo onhandig dat een 'id' veld snellere resultaten geeft

[Standeman]

LAST_INSERT_ID() ... werkt per connectie en is dus redelijk save om te gebruiken

overigens eerste wat ik te lezen krijg in de MySQL doc's als ik zoek op auto_increment

http://dev.mysql.com/doc/...ample-AUTO_INCREMENT.html

[Verwijderd]

BasieP schreef op vrijdag 31 december 2004 @ 14:15:
Trouwens is een nog betere oplossing natuurlijk, het maken van een primairy key over velden die je gebruikt bij je invoer, ipv een 'id' veld te gebruiken
op deze manier heb je dus sowieso geen auto increment, en heb je altijd de primairy key direct te pakken. alleen dit is dan weer niet altijd mogelijk, of zo onhandig dat een 'id' veld snellere resultaten geeft

Gaat niet werken. Je bent nmlk afhankelijk van je user input dus krijg je dubbele waarden.

[StevenK]

BasieP schreef op vrijdag 31 december 2004 @ 14:15:
Trouwens is een nog betere oplossing natuurlijk, het maken van een primairy key over velden die je gebruikt bij je invoer, ipv een 'id' veld te gebruiken
op deze manier heb je dus sowieso geen auto increment, en heb je altijd de primairy key direct te pakken. alleen dit is dan weer niet altijd mogelijk, of zo onhandig dat een 'id' veld snellere resultaten geeft

Nee, dat is zeker geen betere oplossing. Je moet zeker niet je gecombineerde data als PK gebruiken, al is het alleen maar omdat je zo'n PK nooit als FK kunt gebruiken.

[Gert]

Dat ligt geheel aan wat de data voorstelt. Een auto id hebben gewoon omdat je te lui bent om zelf een goede key uit te zoeken is niet de juiste reden. Als dat id helemaal nooit meer gebruikt wordt binnen je applicatie is het nutteloos en dus niet nodig.
Je kan trouwens prima een relatieleggen middels meer dan 1 veld, dus dat is geen reden om het niet te doen.
D'r zijn meerdere stromingen hierin. Er zijn ook aanhangers die altijd een enkel id veld willen hebben.

[ Voor 13% gewijzigd door Gert op 31-12-2004 15:13 ]

[Standeman]

In principe wordt altijd aangeraden om zogenaamde logische sleutels te gebruiken. Deze maken je datamodel een stuk begrijpelijker en je data leesbaarder.
Technische sleutels moet je eigenljik alleen gebruiken wanneer

a) een logische sleutel niet mogelijk is door de aard van de data
b) je performance problemen hebt.

Gaat niet werken. Je bent nmlk afhankelijk van je user input dus krijg je dubbele waarden.

Userinput heeft geen mallemoer te maken of data al dan niet geidentificeerd kan worden aan de velden van een row. Het is namelijk net zo goed dat je dubbele waarden absoluut wil mijden! Met een technische sleutel is dat weer niet echt af te dwingen (m.u..v. constraints, etc, etc)

[ Voor 38% gewijzigd door Standeman op 31-12-2004 15:26 ]

[BasieP]

Verwijderd schreef op vrijdag 31 december 2004 @ 14:30:
[...]


Gaat niet werken. Je bent nmlk afhankelijk van je user input dus krijg je dubbele waarden.

mja dat is met mysql dan misschien weer zo, maar in oracle ofzo kan je prima je PK over meerdere velden maken hoor, je PK is unique, dus dan word je user input door de DB gecheckt, en krijg je gewoon een error terug

StevenK schreef op vrijdag 31 december 2004 @ 14:35:
[...]

Nee, dat is zeker geen betere oplossing. Je moet zeker niet je gecombineerde data als PK gebruiken, al is het alleen maar omdat je zo'n PK nooit als FK kunt gebruiken.

dat hoeft ook helemaal niet, als jij bijv een database maakt als volgt

klant: voornaam, achternaam, adres, telefoonnr, etc.
order: ordernr, voornaam, achternaam, datum, etc.
orderregel: poepveld, (bijv auto inc.), ordernr, artikelnr, aantal

waar bold de tablename is van een tabel waar underline de PK is die verwijst naar italic uit een andere table

een PK hoeft nooit een FK te worden, (ik ben er trouwens wel even van uit gegaan dat voornaam en achternaam nu voldoende is om een klant te identificeren, dat is in de praktijk soms dus anders)

in mijn voorbeeld kan je dus zien, zoals hierboven gezegt, dat logische sleutels gebruikt worden, tenzij het niet anders kan, de tabel klant heeft hier wel logische sleutels, omdat deze geidentificeerd word door de klantvoornaam en achternaam.
de laatste tabel (orderregel) hoeft niet los geidentificeerd te worden, en alle velden uit die tabel mogen vaker voorkomen, zelfs alle mogelijke combinaties mogen vaker voorkomen
voor dit soort tabellen moet je dus WEL een extra kolom maken, en daar dan je PK op zetten.

[ Voor 73% gewijzigd door BasieP op 31-12-2004 15:51 ]

[Verwijderd]

BasieP schreef op vrijdag 31 december 2004 @ 15:30:
mja dat is met mysql dan misschien weer zo

Ongefundeerd MySQL bashen is natuurlijk wel leuk, maar net zo indrukwekkend als Microsoft bashen. Het is gewoon te makkelijk, en iedereen doet het al.

Voor de duidelijkheid; ja MySQL ondersteunt een PK over meerdere velden.

een PK hoeft nooit een FK te worden

Qué? Je gebruikt toch de PK van een tabel als FK in een andere tabel, of is jouw definitie van FK anders dan de mijne?

[BasieP]

Verwijderd schreef op vrijdag 31 december 2004 @ 16:51:
[...]

Ongefundeerd MySQL bashen is natuurlijk wel leuk, maar net zo indrukwekkend als Microsoft bashen. Het is gewoon te makkelijk, en iedereen doet het al.

Voor de duidelijkheid; ja MySQL ondersteunt een PK over meerdere velden.

mja teentjes enzo.. misschien is het woord 'misschien' je niet zo opgevallen

Qué? Je gebruikt toch de PK van een tabel als FK in een andere tabel, of is jouw definitie van FK anders dan de mijne?

dat zou best kunnen, FK's zijn nooit me sterkste kant geweest, zou zelfs ni echt meer kunnnen zeggen wat nou precies FK's zijn

edit: mm ik bedenk me net dat het dan ook wel handig is als ik erbij zet wat ik dan d8 bij FK's
FK is een key op een not PK veld
dus bij mijn voorbeeld zou bijv als je straatnaam en huisnamer samen een key geeft, of bijv telefoonnummer (in klant tabel dan in mijn voorbeeld)

deze mogen dan in die tabel maar 1x voorkomen
zo kunnen dus 2 mensen niet hetzelfde telefoonnummer hebben

[ Voor 24% gewijzigd door BasieP op 31-12-2004 18:26 ]

[StevenK]

[b][message=22468542,noline]BasieP schreef op vrijdag 31 december 2004 @ 18:12
edit: mm ik bedenk me net dat het dan ook wel handig is als ik erbij zet wat ik dan d8 bij FK's
FK is een key op een not PK veld
dus bij mijn voorbeeld zou bijv als je straatnaam en huisnamer samen een key geeft, of bijv telefoonnummer (in klant tabel dan in mijn voorbeeld)

deze mogen dan in die tabel maar 1x voorkomen
zo kunnen dus 2 mensen niet hetzelfde telefoonnummer hebben

Een Foreign Key is een referentie naar de Primary Key van een andere tabel; wat jij een FK noemt, is een unique contraint (en als 'ie geïndexeerd is een unique index).

[ Voor 5% gewijzigd door StevenK op 31-12-2004 19:39 ]

[BasieP]

StevenK schreef op vrijdag 31 december 2004 @ 19:38:
[...]

Een Foreign Key is een referentie naar de Primary Key van een andere tabel; wat jij een FK noemt, is een unique contraint (en als 'ie geïndexeerd is een unique index).

ah kijk dan haal ik idd wat dingen door elkaar
mja nou je het zegt, ben op dit moment nogal druk met UC's en andere constraints, dus wel logisch dat ik daar aan dacht

trouwens heb ik dan nog wel gelijk, want een FK kan dan nooit een PK zijn, aangezien de FK in table1 zit en de PK waar die naar verwijst in table2

[StevenK]

BasieP schreef op vrijdag 31 december 2004 @ 19:49:
[...]


ah kijk dan haal ik idd wat dingen door elkaar
mja nou je het zegt, ben op dit moment nogal druk met UC's en andere constraints, dus wel logisch dat ik daar aan dacht

trouwens heb ik dan nog wel gelijk, want een FK kan dan nooit een PK zijn, aangezien de FK in table1 zit en de PK waar die naar verwijst in table2

Ja, joh, jij je zin als je zo graag wil horen dat je gelijk hebt

_{Maar je zou natuurlijk ook kunnen proberen te lezen wat er staat: het lijkt me nogal logisch dat een FK in tabel 1 wijst naar de PK van tabel 2 en de vraag is vooral hoe jij dat op wil lossen wanneer de PK van tabel 2 uit meer velden bestaat.}

[bakakaizoku]

BasieP schreef op vrijdag 31 december 2004 @ 15:30:
[...]


mja dat is met mysql dan misschien weer zo, maar in oracle ofzo kan je prima je PK over meerdere velden maken hoor, je PK is unique, dus dan word je user input door de DB gecheckt, en krijg je gewoon een error terug


[...]


dat hoeft ook helemaal niet, als jij bijv een database maakt als volgt

klant: voornaam, achternaam, adres, telefoonnr, etc.
order: ordernr, voornaam, achternaam, datum, etc.
orderregel: poepveld, (bijv auto inc.), ordernr, artikelnr, aantal

waar bold de tablename is van een tabel waar underline de PK is die verwijst naar italic uit een andere table

Ja, leuk, en wat als er nu 2 Jan Janssen's zijn?

Imo moet een PK totaal data onafhankelijk zijn, iets wat niet op de echte data slaat. Anders krijg je snel geouwehoer met dubbele data..

[ Voor 9% gewijzigd door bakakaizoku op 31-12-2004 22:11 ]

[vorlox]

Imo moet een PK totaal data onafhankelijk zijn, iets wat niet op de echte data slaat. Anders krijg je snel geouwehoer met dubbele data..

Ik kan het natuurlijk ook mis hebben, maar ik ben het volledig met je eens.
Een PK moet altijd data onafhankelijk zijn en naar mijn mening dus ook een auto_increment int zijn.....je moet wel een erg goede reden hebben vind ik om het anders te doen.
Verder vind ik eigenlijk dat het niet eens wat met MySQL te maken heeft. Ik werk zo ook in MsSQL, Oracle, Lotus Notes (voorzover mogelijk ) enz...je wilt toch altijd aan 1 unieke identifier je record kunnen ophalen.

Tevens als je meerdere tekst velden gebruikt als key heb je op een gegeven moment toch ook grotere join statements nodig? Iets wat niet tot performance verbetering leidt.

[Erkens]

mattttt schreef op vrijdag 31 december 2004 @ 22:08:
[...]


Ja, leuk, en wat als er nu 2 Jan Janssen's zijn?

ooit van een voorbeeld gehoord?

Imo moet een PK totaal data onafhankelijk zijn, iets wat niet op de echte data slaat. Anders krijg je snel geouwehoer met dubbele data..

hier ben ik het niet (altijd) mee eens
neem bijvoorbeeld een SOFI nummer, dit is iets wat gegarandeerd uniek is en tevens nooit kan veranderen, en is dus prima te gebruiken als PK (als je dat wilt)
Het ligt helemaal aan de database wat de beste oplossing is

[ACM]

BasieP schreef op vrijdag 31 december 2004 @ 19:49:
trouwens heb ik dan nog wel gelijk, want een FK kan dan nooit een PK zijn, aangezien de FK in table1 zit en de PK waar die naar verwijst in table2

Tuurlijk kan een column tegelijkertijd FK en PK zijn. Neem maar als voorbeeld een tabel met het een of ander en een aanvullende tabel met bijvoorbeeld een zwik optionele dingen met een 1-1 mapping (users, en speciale instellingen ofzo). Dan is het niet perse nodig om voor die aparte tabel een aparte PK op te zetten met auto_increments oid, dan kan je net zo goed de PK van de originele tabel als FK invoegen die tegelijkertijd PK voor die tabel is.

Ander voorbeeld is natuurlijk de overbekende koppeltabel. De columns die samen de PK vormen daarin zijn ook allebei FK.

[Verwijderd]

vorlox schreef op zaterdag 01 januari 2005 @ 13:27:
[...]

Ik kan het natuurlijk ook mis hebben, maar ik ben het volledig met je eens.
Een PK moet altijd data onafhankelijk zijn en naar mijn mening dus ook een auto_increment int zijn.....je moet wel een erg goede reden hebben vind ik om het anders te doen.
Verder vind ik eigenlijk dat het niet eens wat met MySQL te maken heeft. Ik werk zo ook in MsSQL, Oracle, Lotus Notes (voorzover mogelijk ) enz...je wilt toch altijd aan 1 unieke identifier je record kunnen ophalen.

Tevens als je meerdere tekst velden gebruikt als key heb je op een gegeven moment toch ook grotere join statements nodig? Iets wat niet tot performance verbetering leidt.

Ik ben ook aanhanger van het gebruik van het `id` veld. Ten eerste kun je op die manier een record altijd uniek specificeren, zonder noodzaak van impliciete of expliciete constraints op je tabel. Ten tweede, wat je al aangaf, bevordert het de prestatie van queries. Ten derde kan het minder opslagruimte vereisen. Neem nu het voorbeeld eerder gegeven. Nu moet je `voornaam`, `achternaam` in de order vermelden. Als de klant een `id` veld had, had deze de twee velden in de order kunnen vervangen. Dit geeft een extra veld in de klant tabel, en een minder in de order tabel, maar het `id` veld heeft minder opslag nodig dan de string velden. Als de klant nou in nog meer tabellen wordt gekoppeld, loop je nog meer in. Ik meen hoe groter de database, en hoe meer onderlinge relaties, des te meer voordeel je hebt van het `id` veld.

Overigens is het vaak ook handiger om een id veld te hebben in termen van interfaces: het is gemakkelijker om te schrijven "http://www.bla.nl?action=delete&id=245" dan "http://www.bla.nl?action=delete&voornaam=karel&achternaam=appel".

En, ja, ik verveel me.

[Creepy]

Erkens schreef op zaterdag 01 januari 2005 @ 13:32:
[...]

ooit van een voorbeeld gehoord?

Wel een heel fout voorbeeld (nofi) als je namen (!) als PK gaat gebruiken. Namen komen al snel dubbel voor en dan wil ik het nog niet eens hebben om een naam aps FK te gaan gebruiken. Wat als de naam anders word? Dan kan je naast je PK ook ale FK's gaan updaten (rekening houdend met dubbele al bestaande namen)

[...]

hier ben ik het niet (altijd) mee eens
neem bijvoorbeeld een SOFI nummer, dit is iets wat gegarandeerd uniek is en tevens nooit kan veranderen, en is dus prima te gebruiken als PK (als je dat wilt)
Het ligt helemaal aan de database wat de beste oplossing is

Een sofi nummer IS een uniek nummer en veranderd nooit. Een ideaal geval voor een PK dus. Het is ook niet meer dan een nummer en geen "echte" data. Het wordt namelijk alleen als unieke identificatie gebruikt

Dus ik durf hem wel aan: een PK is altijd een uniek nummer, en geen "echte" data

[ Voor 12% gewijzigd door Creepy op 01-01-2005 20:03 ]

[BasieP]

Creepy schreef op zaterdag 01 januari 2005 @ 19:59:
[...]

Wel een heel fout voorbeeld (nofi) als je namen (!) als PK gaat gebruiken. Namen komen al snel dubbel voor en dan wil ik het nog niet eens hebben om een naam aps FK te gaan gebruiken. Wat als de naam anders word? Dan kan je naast je PK ook ale FK's gaan updaten (rekening houdend met dubbele al bestaande namen)

mja dat voorbeeld kwam van mij, en ik heb er EXPICIET bij gezegt dat het alleen geld als je zeker weet dat elke naam maar 1x voorkomt. dus ik snap niet waarom dit 30x gekw00t word met de mooie vermelding dat namen vaker kunnen voorkomen, want dat heb ik er bijgezegt

Een sofi nummer IS een uniek nummer en veranderd nooit. Een ideaal geval voor een PK dus. Het is ook niet meer dan een nummer en geen "echte" data. Het wordt namelijk alleen als unieke identificatie gebruikt

mja in dit geval is een sofi nummer ook data hoor

als bijv op een school elke student een nummer heeft met ze geboortedatum+een volgnummer bijv dan is dat ook uniek, en zit er echt data in (je zou dan zelfs het geboortedatum veld kunnen schrappen)

[ Voor 65% gewijzigd door BasieP op 01-01-2005 20:03 ]

[Creepy]

BasieP schreef op zaterdag 01 januari 2005 @ 20:01:
[...]

mja dat voorbeeld kwam van mij, en ik heb er EXPICIET bij gezegt dat het alleen geld als je zeker weet dat elke naam maar 1x voorkomt. dus ik snap niet waarom dit 30x gekw00t word met de mooie vermelding dat namen vaker kunnen voorkomen, want dat heb ik er bijgezegt

Je vergeet dat naast dat het maar 1 keer mag voorkomen, het ook niet niet mag veranderen. En ja, er zijn mensen die hun naam veranderen. Nu moet je dus je naast je PK ook alle FK's waarin deze PK zit aanpassen.

BasieP schreef op zaterdag 01 januari 2005 @ 20:01:
als bijv op een school elke student een nummer heeft met ze geboortedatum+een volgnummer bijv dan is dat ook uniek, en zit er echt data in (je zou dan zelfs het geboortedatum veld kunnen schrappen)

Het blijft een uniek nummer zonder betekenis. Het maakt niet uit hoe dat nummer is samengesteld of bepaald of dat er andere gegevens zijn uit te halen. Naast dat (volg)nummer heb je namelijk los de echte gegevens: Naam, inschrijfdatum, geboorte datum etc.

[ Voor 41% gewijzigd door Creepy op 01-01-2005 20:09 ]