[SQL] autoincrement onvoorspelbaar...

[T-MOB]

Ik ben bezig met een database-applicatie met PHP en MySQL. Van een pagina met een formulier worden gegevens gepost naar het verwerkingsscript dat deze gegevens (controleert en) in de database opslaat in 4 tabellen. De eerste tabel die wordt bijgewerkt bevat een auto_increment id. Die wordt echter ongewenst gereset.

De eerste query die wordt uitgevoerd is ongeveer deze:

code:

INSERT INTO pge_datasets 
    (datasetid, archive, archivenumber, institution, name, response, election) 
VALUES 
    (NULL,'TMOB','007','TEST','Testnaam','562','0')

met mysql_insert_id() wordt het id opgehaald en worden de overige 3 tabellen gevuld. Als dit goed gaat wordt op de eerste tabel update query uitgevoerd op een veld dat de status van de entry aangeeft:

code:

UPDATE pge_datasets 
SET 
     status = '1' 
WHERE 
     datasetid = '" .$id ."' 
LIMIT 1

Wat ik hoopte te bereiken was een lijst met opeenvolgende id's. Die onstaat echter niet (zie plaatje hieronder). Ik heb zelf 2 mogelijke oorzaken kunnen bedenken:
1. "status" is een reserved woord in MySQL, door de update wordt de auto_incrment vernaggeld. (dat hoop ik niet want wordt hoop aanpaswerk).
2. Ik heb een index liggen over het het id 'datasetid' en het veld 'election'. Er wordt op basis van de waarde van 'election' gekeken of het id opgehoogd moet worden. Dat strookt wel redelijk met het plaatje van de testcases:

Is er iemand die hier uitsluitsel over kan geven, alvorens ik mijn scripts overhoop haal?

[Zoijar]

auto increment geeft helemaal geen garantie dat er opvolgende getallen worden aangemaakt. Het enige dat belooft wordt is dat het getal uniek is.

[Verwijderd]

Het woord status is geen reserved word in MySQL, zie http://dev.mysql.com/doc/mysql/en/Reserved_words.html

Je hoeft niet per se alle waarden op te geven met je INSERT query, ik zou bijv. liever doen:

SQL:

INSERT INTO pge_datasets 
    (archive, archivenumber, institution, name, response, election) 
VALUES 
    ('TMOB','007','TEST','Testnaam','562','0')

Het is etenstijd dus meer kan ik er even niet over zeggen...

[T-MOB]

Zoijar schreef op 16 juli 2004 @ 18:56:
auto increment geeft helemaal geen garantie dat er opvolgende getallen worden aangemaakt. Het enige dat belooft wordt is dat het getal uniek is.

Nou ja, mits er niet gedelete wordt zijn ze doorgaans opvolgend. Het punt is natuurlijk dat ze niet uniek zijn.

Verwijderd schreef op 16 juli 2004 @ 18:58:
Het woord status is geen reserved word in MySQL, zie

Je hoeft niet per se alle waarden op te geven met je INSERT query, ik zou bijv. liever doen: [...]

Zo stond het er eerst ook, ik had de id er expliciet bijgezet omdat het misging...

En als status niet gereserveerd is dan zal ik eens met de index aan het sleutelen.

[ Voor 10% gewijzigd door T-MOB op 16-07-2004 19:06 ]

[Zoijar]

T-MOB schreef op 16 juli 2004 @ 19:03:
Nou ja, mits er niet gedelete wordt zijn ze doorgaans opvolgend. Het punt is natuurlijk dat ze niet uniek zijn.

Nee, dat hoeft dus helemaal niet Een implementatie mag ook een random getal aanmaken en kijken of dat uniek is, zo ja het gebruiken, en anders opnieuw.

Niet geinitialiseerd geheugen is ook doorgaans nul(l), en soms ineens niet, en dan crashed de boel "ineens".

[ Voor 14% gewijzigd door Zoijar op 16-07-2004 19:06 ]

[T-MOB]

Zoijar schreef op 16 juli 2004 @ 19:05:
[...]

Nee, dat hoeft dus helemaal niet Een implementatie mag ook een random getal aanmaken en kijken of dat uniek is, zo ja het gebruiken, en anders opnieuw.

Niet geinitialiseerd geheugen is ook doorgaans nul(l), en soms ineens niet, en dan crashed de boel "ineens".

Owkee, maar ze zijn niet uniek (zie plaatje). Voor zover ik kan zien zijn ze uniek bij een gelijke waarde voor `election`. Vandaar de link met de index...

[Zoijar]

Wat is je PK dan? Want als dat alleen datasetid is, dan kan dit niet. Moet je een bug report filen. Is dat niet archivenumber erbij ofzo? Voor een niet PK hoeft een auto inc ook niet uniek te zijn.

[T-MOB]

Zo te zien heb ik geen Primary Key aangemaakt . Dan zal dat hem wel zijn, ga gelijk ff testen.

[Verwijderd]

T-MOB schreef op 16 juli 2004 @ 19:22:
Zo te zien heb ik geen Primary Key aangemaakt . Dan zal dat hem wel zijn, ga gelijk ff testen.

Haha, handig!

Je kan trouwens ook zorgen dat je ID uniek is door de volgende SQL te gebruiken:

SQL:

ALTER TABLE `tabelnaam` ADD UNIQUE (
`id` 
)

(en even veranderen zodat het in jouw context past)

[edit]Waarom heb je trouwens gekozen voor de eigenschappen [UNSIGNED] en [ZEROFILL] over je ID kolom?

[ Voor 13% gewijzigd door Verwijderd op 16-07-2004 20:06 ]

[T-MOB]

Verwijderd schreef op 16 juli 2004 @ 20:03:
[...]


Haha, handig!

Je kan trouwens ook zorgen dat je ID uniek is door de volgende SQL te gebruiken:

SQL:

ALTER TABLE `tabelnaam` ADD UNIQUE (
`id` 
)

(en even veranderen zodat het in jouw context past)

[edit]Waarom heb je trouwens gekozen voor de eigenschappen [UNSIGNED] en [ZEROFILL] over je ID kolom?

De UNSIGNED is min of meer een overblijfsel van een ander ding dat ik ooit gemaakt heb. Daar gebruikte ik een mediumint(7) als id, en die wil je wel unsigned hebben voor de laatste 1.611.393 waarden. Overigens voer ik overal waar ik een positieve waarde verwcht / wil hebben UNSIGNED in, nooi echt over nagedacht.
ZEROFILL is een stukje luiïgheid, dan hoef je geen natsort() te gebruiken in PHP om te sorteren op id (voor zover ik weet is in MySQL sorteren op auto_increment gelijk aan sorteren op invoertijdstip).
waarom zou je dat willen?
Omdat er buiten de applicatie ook met de id's gewerkt moet worden.
Is dat noodzakelijk?
Nee, niet echt, maar als je toch een database opbouwt dan zijn de id's een heerlijk aanknopingspunt om bestandsnamen op af te stemmen. Per entry zijn er zo'n 7 bestanden die met een numerieke prefix erg snel zijn terug te vinden. (En het OS doet ook niet echt aan natural sorting...).
/offtopic

M'n probleem is verder opgelost, dus bedank allemaal