[mySQL][PHP] ID weten voordat er een insert is uitgevoerd

[wustenveld]

Ik heb al met de search gezocht naar informatie waar ik wat mee kan maar kan toch niks vinden. Ik wil in een insert formulier de gebruiker laten zien wat het ID zal zijn als het record ingevoegd is. Het id is een auto_increment veld. Nu kan ik natuurlijk het hoogte id opzoeken en optellen met 1 maar dat werkt niet als er voor een toevoeging net de laatste 5 records verwijderd zijn. Dan is het nieuwe ID (hoogte ID + 5). Wordt er ergens in mysql opgeslagen wat het nieuwe auto_increment id zal zijn voor een veld. Je kunt wel het laatst toegevoegde ID opzoeken maar als je van te voren nog niks hebt toegevoegd blijft de waarde die je terug krijgt leeg.

dus is het mogelijk om de nieuwe auto_incremented id te weten voordat het record is toegevoegd ??

[D2k]

kan niet (of je moet een MAX query ervoor doen, maar als er dan 2 tegelijk worden ingevoerd weet je nog nix)

[Skinny]

Weet ik wat er aan de andere kant van de deur is, voordat ik hem open heb gedaan ?

Ja, je kan door het sleutelgat kijken, het aan iemand vragen die er al geweest is, maar dit zijn allemaal oplossingen die niet echt betrouwbaar zijn. Hetzelfde geldt voor het opvragen van de volgende ID.. je weet nooit wat erintussen gebeurd.


Dat auto-increment ID is als het goed is niets meer dan een uniek nummer dat je gebruikt als primary-key. Of dit nu 1, 2, 3 of 1, 100, 600 loopt, dat hoort niets uit te maken.

[djc]

Insert een record met herkenbare informatie (een session_id oid) voordat je het form laat zien. Kan je die gegevens daarna vervangen bij het echte inserten.

[akakiwi]

Wat je kunt doen is het volgende
Geef een lege INSERT op de tabel voordat je het form inlaad. Dan SELECT @@IDENTITY, en update dat Id nadat de gebruiker het form heeft gesubmit.

Groot nadeel is wel dat alle columns uit je tabel NULL waarden moeten accepteren.

[whoami]

D2k schreef op 15 oktober 2002 @ 15:19:
kan niet (of je moet een MAX query ervoor doen, maar als er dan 2 tegelijk worden ingevoerd weet je nog nix)

Een select max() gaat niet noodzakelijk het juiste id teruggeven dat het record gaat krijgen als het een auto-inc veld is.
Stel dat je max. id nu 4 is, en je verwijdert record met id 4.
Daarna voeg je een record toe, en om het id te weten doe je een select max(). Je gaat dan als resultaat 3 krijgen, en je verwacht dan dat jouw record id 4 gaat krijgen.
Echter, het nieuwe record zal id 5 krijgen.

[wustenveld]

Akakiwi goed idee. En je columns hoeven eigenlijk dan ook geen NULL waarden te accepteren door zomaar wat dummy data erin te zetten de eerste keer die later weer overschreven wordt door de data uit het formulier. Daarnaast heb ik het formulier zo gemaakt dat ie eerst checkt op waarden die verplicht ingevuld moeten worden.

Alleen dan zie ik een ander probleem en dat is dat als de gebruiker eigenlijk toch stiekum niks wilt toevoegen er wel een lege insert is uitgevoerd.

[whoami]

akakiwi schreef op 15 oktober 2002 @ 15:43:
Wat je kunt doen is het volgende
Geef een lege INSERT op de tabel voordat je het form inlaad. Dan SELECT @@IDENTITY, en update dat Id nadat de gebruiker het form heeft gesubmit.

Groot nadeel is wel dat alle columns uit je tabel NULL waarden moeten accepteren.

Hmmm...... Niet echt een mooie oplossing, maar eventueel biedt dit wel uitkomst. Je columns moeten wel null accepteren, en dat is niet altijd het geval.

Maar waarom zou je het id van het record willen weten voor het geinsert is? IMHO mag een PK geen enkele informatieve waarde hebben.

[whoami]

wustenveld schreef op 15 oktober 2002 @ 15:46:
Alleen dan zie ik een ander probleem en dat is dat als de gebruiker eigenlijk toch stiekum niks wilt toevoegen er wel een lege insert is uitgevoerd.

Transactions!

[Janoz]

Zelfs al zou je het autoinc id op kunnen vragen voor de select.. Dat zou nog steeds niet betekenen dat dit de juiste is.

persoon a vraagt registratie pagina op en volgende id zou X worden.
persoon b vraagt registratie pagina op en volgende id zou weer X worden omdat a nog niet klaar is.
persoon a stuurt de boel op en krijgt dus werkelijk id X.
persoon b stuurt nu op maar krijgt dus als id Y waarbij Y het volgende auto ID na X is.

[Verwijderd]

Je kunt ook een teller tabeltje gebruiken waar je de id's in bij houdt. Nadeel is dat dit wel extra query's kost. Voordeel is dat je altijd van elke tabel het next_id kunt voorspellen.

[Defspace]

Verwijderd schreef op 15 oktober 2002 @ 15:49:
Je kunt ook een teller tabeltje gebruiken waar je de id's in bij houdt. Nadeel is dat dit wel extra query's kost. Voordeel is dat je altijd van elke tabel het next_id kunt voorspellen.

Nou dit is wel de meest ranzige oplossing die ik hier tussen zie staan.
Daarbij, kan ik als admin besluiten de next insert id opeens met 200 te verhogen oid. Dan heb je dus nog niet de juiste.

Nextval vragen (de beste) of Insert en dan update lijkt me idd de beste keuze.

[Verwijderd]

Daarbij, kan ik als admin besluiten de next insert id opeens met 200 te verhogen oid. Dan heb je dus nog niet de juiste.

Dat zou
a) lomp zijn, want welke admin met een beetje verstand in zijn hoofd bemoeit zich op db-nivo met tellers en waarom zou je het uberhaubt willen ophogen.

b) is het onzin want mocht de onverstandige admin de teller met 200 ophogen is het next_id gewoon de waarde die er in de tabel staat. Het idee achter deze methode is dat je namelijk de auto_increment van de database helemaal vergeet!

Voordeel is als je dit op een nette abstractie laag toe past, het dus ook werkt op databases die GEEN eigen auto-increment feature kennen.
(soms moet je verder kijken als de mysql neus lang is )

[whoami]

Defspace schreef op 15 oktober 2002 @ 15:59:
[...]

Nou dit is wel de meest ranzige oplossing die ik hier tussen zie staan.
Daarbij, kan ik als admin besluiten de next insert id opeens met 200 te verhogen oid. Dan heb je dus nog niet de juiste.

Nextval vragen (de beste) of Insert en dan update lijkt me idd de beste keuze.

Dat vind ik geen ranzige oplossing.
Ik gebruik dit zelf ook soms.

[dirkpostma]

Ik wil in een insert formulier de gebruiker laten zien wat het ID zal zijn als het record ingevoegd is.

Mag ik vragen waarom je dit wilt? Ik kan mij zo geen situatie voorstellen waarin dit interessant is. En, je kunt het id toch ook laten zien nadat het record is ingevoegd? Of wil iets totaal's niet standaard wat toch interessant is?

Just curious . En misschien, als de context duidelijk is, dat er nog betere alternatieven aangedragen zullen worden.

[Defspace]

Verwijderd schreef op 15 oktober 2002 @ 16:11:
[...]


Dat zou
a) lomp zijn, want welke admin met een beetje verstand in zijn hoofd bemoeit zich op db-nivo met tellers en waarom zou je het uberhaubt willen ophogen.

Nou vooruit. Dat gebeurt niet veel idd. (Toevallig laatst gedaan vanwege database conversie)

b) is het onzin want mocht de onverstandige admin de teller met 200 ophogen is het next_id gewoon de waarde die er in de tabel staat. Het idee achter deze methode is dat je namelijk de auto_increment van de database helemaal vergeet!

Ok, ik heb je dan verkeerd begrepen

Voordeel is als je dit op een nette abstractie laag toe past, het dus ook werkt op databases die GEEN eigen auto-increment feature kennen.
(soms moet je verder kijken als de mysql neus lang is )

Mag het in mijn geval mijn PostgreSQL neus zijn (zie daar heb je hem)

[wustenveld]

Ik ben dus bezig met de ontwikkeling van een zelfgenererend CMS Systeem. Hij genereert zichzelf op basis van de database structuur en een bestand waar allerlei variabelen in staan. Dit CMS is toepasbaar op alle websites die ik voor m'n werk maak en ik bespaar hier aardig wat tijd mee. Ik hoef me nu alleen nog maar druk te maken om de website en niet om het achterliggend CMS Systeem. Daarnaast als ik nieuwe dingetjes bedenk voor zo'n CMS (bijvoorbeeld een betere HTML Editor) kan ik in één keer alle oudere CMS'en updaten.

Nu is het dus het geval dat ik in een formulier een groep heb die gekozen moet worden door middel van een pull-down menu. De waardes komen uit een tabel die gevuld is met allerlei waarden. Echter is er geen één kolom die uniek is behalve de ID. Het gaat om een tabel met woningtypen (id, wijk, type). De ID wordt gebruikt om oa foto's van zo'n woningtype te koppelen (type[x].jpg). Nu staat het niet mooi om alleen het ID in het pull-down menu te tonen en wou ik dus het ID in combinatie met het type tonen in het pulldown menu. Om dat te bereiken heb ik een veld titel toegevoegd waarin eerst het ID en dan het type ingevuld moet worden door de gebruiker.

Omdat dit niet zo vaak voorkomt wil ik de pull-downs niet standaard vullen met [id]-[titel] maar alleen bij deze. Vandaar een extra veld. Echter als de gebruiker dus een woningtype invult moet hij/zij wel weten welk nummer ingevuld moet worden bij de titel en die weet ie pas nadat de type is ingevoerd. Om de handelingen te verminderen wou ik dus het nieuwe ID tonen voordat het gesubmit is.

Maar goed, terwijl ik dit typ heb ik dus al wat bedacht. Zodra groepen uit een database tabel gehaald worden moet voor die groep in het variabelen bestand aangegeven worden dat ook het ID in het pull-down menu getoond moet worden. Standaard zal dat FALSE zijn maar in het geval van deze woningtypen TRUE. Ik denk dat ik het zo wel kan oplossen en dus voor het CMS visueel niks met het ID meer te maken heb.

Toch wel handig als je probeert iets uit te leggen dat je tegelijkertijd nadenkt over een oplossing. :-P Sorry voor deze discussie.

Maar toch ben ik benieuwd naar ander oplossingen voor het weten van het ID voordat deze ingevoerd is ook heb ik niet voor dit ding nodig.

[Crazy D]

Volgens mij heb ik 'm gemist (en ja drm anders ben ik weer een spuit 11 ) maar waarom zou je dat willen weten Ik kan eigenlijk geen fatsoenlijk voorbeeld bedenken waarbij het echt van belang is dat je, voordat je op save drukt, al vast weet welk ID het record gaat krijgen.
Maar goed, een lege insert is ook niet alles, dan moet je bij het opvragen van die data wel weer rekening houden dat er lege records in kunnen voorkomen (wat nou als de gebruiker z'n browser sluit, nadat ie je form heeft opgevraagt), of eens in de zoveel tijd die records laten wijzigen. Dan vind ik een aparte tabel op zich handiger en netter.
Transactions zouden op zich wel aardig zijn, alleen denk ik dat je een transactie niet op pagina1 wilt laten beginnen, en op pagina2 wilt laten eindigen...

[wustenveld]

Transacties is idd een goed idee, maar is dit ook mogelijk met mySQL ???

[Bosmonster]

Een zelf-genererend CMS..

Lijkt me erg gebruikersvriendelijk.. Soort van tabellenbeheer voor de gebruiker.. Geef ze dan phpMyAdmin..

Ok.. offtopic, zeker voor /14, maar jammer dat er zelden of nooit naar interaction design van een CMS gekeken wordt.. Dit wordt meestal maar met als uitgangspunt de DB en dus de ontwikkelaar in elkaar gezet, zonder te denken aan enige vorm van gebruiksvriendelijkheid. De klant denkt nu eenmaal niet in tabellen...

heb je overigens al eens gekeken naar mysql_inserted_id() en dergelijken? Daarmee kun je wel de auto-generated ID opvragen van je laatste insert..

[_js_]

Met mysql commando
SHOW TABLE STATUS LIKE 'tabelnaam'
krijg je onder andere het eerst volgende auto increment nummer terug (in de kolom met de naam Auto_increment).

[Verwijderd]

misschien dom, maar kan je met MySQL geen tables locken

[cameodski]

whoami schreef op 15 oktober 2002 @ 15:48:
Transactions!

Wil je dit alsjeblieft nooit meer zeggen!!!!!!
Een gebruiker wil een record gaan toevoegen en er wordt meteen een record toegevoegd, zodat het nieuwste id bekend is.
Vervolgens loopt gebruiker weg en komt bijvoorbeeld een half uur later terug te om op OK te klikken.
Dan wordt te transactie dus pas na een half uur ge-commit.
Binnen een transactie wordt er altijd het een en ander gelockt en dus kan het gebeuren dat hierdoor de rest van de gebruikers moet wachten tot die ene gebruiker zin heeft om een keertje op OK te gaan klikken.

Binnen een transactie mogen in principe geen gebruikeracties plaats vinden. Anders zul je de transactie moeten splitsen en iets met statussen oid gaan doen.

[whoami]

cameodski schreef op 16 oktober 2002 @ 10:48:
[...]

Wil je dit alsjeblieft nooit meer zeggen!!!!!!

Neen.

Een gebruiker wil een record gaan toevoegen en er wordt meteen een record toegevoegd, zodat het nieuwste id bekend is.
Vervolgens loopt gebruiker weg en komt bijvoorbeeld een half uur later terug te om op OK te klikken.
Dan wordt te transactie dus pas na een half uur ge-commit.
Binnen een transactie wordt er altijd het een en ander gelockt en dus kan het gebeuren dat hierdoor de rest van de gebruikers moet wachten tot die ene gebruiker zin heeft om een keertje op OK te gaan klikken.

Binnen een transactie mogen in principe geen gebruikeracties plaats vinden. Anders zul je de transactie moeten splitsen en iets met statussen oid gaan doen.

Hierin heb je wel gelijk. Een transactie duurt best zo kort mogelijk, en begint dus het best wanneer de user op 'Ok' klikt om het record te gaan bewaren.

Als de TS echt het nummer op voorhand wil weten en het gaat doen door eerst een insert te doen (zodat hij het id weet), en daarna het lege record te gaan updaten met de uiteindelijke waarden, dan kan hij het lege record verwijderen als er niet op OK geklikt wordt, maar als er op cancel geklikt wordt oid.
Het Id is nu toch bekend, dus is het makkelijk om dat ene record eruit te halen.
Natuurlijk is het wel mogelijk dat de gebruiker de browser afsluit zonder op ok of cancel te klikken, maar in de on_session_end event oid kan je ook nog wel dat lege record verwijderen mocht dat nodig blijken.

[cameodski]

Het toevoegen van een record voordat een gebruiker op OK geklikt heeft, is in heel veel gevallen absoluut NOT DONE.
Stel dat er een of ander veld is, wat uniek moet zijn en je bent zo snugger om dat maar eens af te laten dwingen door je RDBMS, hoe zou je dat dan willen doen als twee gebruikers tegelijk een record aan het toevoegen zijn?
wustenveld: kun je niet achteraf een of andere message tonen met het nummer van het zojuist toegevoegde record?

TS

[wustenveld]

cameodski: Dat zou ik inderdaad ook kunnen doen. Misschien wil ik gewoon weer dingen die veel te omslachtig of niet normaal zijn. Het systeem wat ik schrijf wordt over het algemeen gebruikt door een gebruiker tegelijkertijd qua toevoegingen en bewerkingen. Dus als ik dmv SHOW TABLE STATUS LIKE 'tabelnaam' het volgende ID bepaal klopt dat wel.

Een record toevoegen voordat er ook maar iets is ingevuld is idd niet echt zo'n goed plan, mede door de velden die uniek moet zijn of iets dergelijks. Inmiddels heb ik hetgene waar ik om vroeg ook niet meer echt nodig maar het is wel interessant om over na te denken, tenminste dat vind ik dan

[whoami]

cameodski schreef op 16 oktober 2002 @ 11:01:
Het toevoegen van een record voordat een gebruiker op OK geklikt heeft, is in heel veel gevallen absoluut NOT DONE.
Stel dat er een of ander veld is, wat uniek moet zijn en je bent zo snugger om dat maar eens af te laten dwingen door je RDBMS, hoe zou je dat dan willen doen als twee gebruikers tegelijk een record aan het toevoegen zijn?
wustenveld: kun je niet achteraf een of andere message tonen met het nummer van het zojuist toegevoegde record?

TS

Daar ga ik volledig mee akkoord, maar als de topicstarter nu perse het id wil weten voordat het record geinsert is en gebruik wil maken van auto-id, heb je geen andere keus, maar ik ga er dus volledig mee akkoord dat het ranzig is.

[dream0r]

Uhmz, of ik lees verkeerd, maar je bedoeld toch dat je het ID krijgt van een auto_increment van vorige query? Dit kan in zelfde script meteen.

PHP:

$last_id = mysql_insert_id();

$last_id bevat dan het ID nummer van laatste INSERT query in script.

[whoami]

Skizzik schreef op 17 oktober 2002 @ 10:35:
Uhmz, of ik lees verkeerd, maar je bedoeld toch dat je het ID krijgt van een auto_increment van vorige query? Dit kan in zelfde script meteen.

PHP:

$last_id = mysql_insert_id();

$last_id bevat dan het ID nummer van laatste INSERT query in script.

Je leest het verkeerd.
Hij wil het id weten van het nieuwe record voordat het record geinsert is.

[DukeMan]

Wat je ook kan doen is het volgende:
- Gebruiker komt op je pagina en je creeert een id door een insert op je db los te laten met een unieke waarde in een veld. Tevens zet je in een (extra) kolom waar bijvoorbeeld NOOIT datums instaan, de huidige datum en tijd weg.
- Met select haal je id op van unieke waarde.
- ID laat je zien aan gebruiker.
- Gebruiker besluit te posten: je hebt het id en je doet een update. Het veld met de datum/tijd overschrijf je eventueel met de werkelijke data (wanneer je geen aparte kolom gebruikt)
- Wanneer volgende gebruiker komt, begin je weer boven aan, maar doe je voordat je de insert doe, een select op de datum/tijd combi en controleer je of deze er al (bijv) een uur in staan. Zo ja, verwijder je ze uit de db. Zo voorkom dat er lege records in je db komen.

is misschien wat omslachtig, maar wel wat je wilt...

[whoami]

NTGiant: lees de draad, voor je blaat.

[DukeMan]

whoami schreef op 17 oktober 2002 @ 11:10:
NTGiant: lees de draad, voor je blaat.

Want? wat bedoel je????

[douweh]

In phpMyAdmin kan je terug vinden, wat de AutoIndex van het volgende record zal worden, dan moet je dat toch ook terug kunnen krijgen in je scriptje..?
ff de source van phpMyAdmin doornemen dus, denk ik?
(ik kan het mis hebben)

[dream0r]

whoami schreef op 17 oktober 2002 @ 10:49:

[...]

Je leest het verkeerd.
Hij wil het id weten van het nieuwe record voordat het record geinsert is.

Mjah s0rry, daar is geen standaard functie voor zover ik weet.