[MySQL] Voorspellen wat de volgende ID wordt in lege tabel?

woensdag 26 mei 2004 17:33

Stelt zich vragen...

Topicstarter

K, ik zal PHPMyAdmin installeren. Weet je eventueel ook waar ergens (in welk odnerdeel/pagina/...) die functie in PHPMyAdmin voorkomt?

Acties:

woensdag 26 mei 2004 17:33

Maar waar heb je dat ID dan voor nodig? Als je het aantal records wilt tellen kun je COUNT gebruiken. En hoe wil je dat doen als er gaten in de ID's zitten?
Aan een auto increment moet je altijd zo weinig mogelijk logica hangen.

Never underestimate the power of

Acties:

woensdag 26 mei 2004 17:33

Bij de query SHOW TABLE STATUS komt er een column met de naam Auto_increment

.

@cameodski: Dat gaat niet als de gebruikers uit die tabel worden verwijdert als de aanmelding succesvol is. En de TS wil het aantal gebruikers die zich hebben geregistreerd (en als ik zo lees alle dus ook degene die de registratie niet hebben afgerond).

[ Voor 60% gewijzigd door Shadowman op 26-05-2004 17:35 ]

Acties:

Schelte

Ik snap je niet helemaal, maar kun je het niet gewoon met mysql_num_rows doen?

code:

<?php

$select = mysql_query("Select id From tabel Where status = 'kandidaat'");
$aantal = mysql_num_rows($select);

if($aantal == 0)
{
    echo "Er zijn <b>0</b> kandidaten.";
}
else
{
    echo "Er zijn <b>".$aantal."</b> kandidaten.";
}

?>

woensdag 26 mei 2004 17:36

Acties:

mjax

Erg ranzig om het aantal records te bepalen a.h.v. de waarde van het hoogste ID.

Voor MyIsam tabellen is een select count(*) de snelste oplossing, omdat MySQL hiervoor geoptimaliseerd is. Bij MyIsam tabellen wordt het aantal records nl. ook bij de tabel opgeslagen. Er worden bij een select count(*) dus niet echt een query op de tabel uitgevoerd en daarom is deze zeer snel. Geldt niet voo InnoDB tabellen overigens...

woensdag 26 mei 2004 17:38

Acties:

MisterData

SELECT LAST_INSERT_ID() kan geloof ik ook gewoon hoor

woensdag 26 mei 2004 17:39

Acties:

LuCarD

Certified BUFH

Shadowman schreef op 26 mei 2004 @ 17:33:
Bij de query SHOW TABLE STATUS komt er een column met de naam Auto_increment .

Uit de handleiding....
http://dev.mysql.com/doc/mysql/en/SHOW_TABLE_STATUS.html

MisterData schreef op 26 mei 2004 @ 17:38:
SELECT LAST_INSERT_ID() kan geloof ik ook gewoon hoor

Werkt niet by mij. Kan het zijn dat de waarde gereset word zodra je de verbinding verbreekt? Of zodra de server reset?

@Alle andere mensen:
Lezen is ook een vak!

De TS wil de volgende ID Nummer hebben van een lege tabel.

[ Voor 27% gewijzigd door LuCarD op 26-05-2004 17:41 ]

Programmer - an organism that turns coffee into software.

woensdag 26 mei 2004 17:40

Acties:

woensdag 26 mei 2004 17:43

Shadowman schreef op 26 mei 2004 @ 17:33:
Bij de query SHOW TABLE STATUS komt er een column met de naam Auto_increment .

@cameodski: Dat gaat niet als de gebruikers uit die tabel worden verwijdert als de aanmelding succesvol is. En de TS wil het aantal gebruikers die zich hebben geregistreerd (en als ik zo lees alle dus ook degene die de registratie niet hebben afgerond).

En wat maakt het uit als ze zijn verwijderd? Je kunt toch op beide tabellen een COUNT (*) doen?

Schelte schreef op 26 mei 2004 @ 17:33:
Ik snap je niet helemaal, maar kun je het niet gewoon met mysql_num_rows doen?
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php

$select = mysql_query("Select id From tabel Where status = 'kandidaat'");
$aantal = mysql_num_rows($select);

if($aantal == 0)
{
    echo "Er zijn <b>0</b> kandidaten.";
}
else
{
    echo "Er zijn <b>".$aantal."</b> kandidaten.";
}

?>

En ook hier kun je veel beter select count (*) doen ipv eerst een hele bak records op te halen en vervolgens in php te gaan tellen.

LuCarD schreef op 26 mei 2004 @ 17:39:
[...]
@Alle andere mensen:
Lezen is ook een vak!

De TS wil de volgende ID Nummer hebben van een lege tabel.

En het gelezene daarna goed verwerken is het vervolgvak

[ Voor 16% gewijzigd door cameodski op 26-05-2004 17:43 ]

Never underestimate the power of

Acties:

maartenba

Met de MySQL LAST_INSERT_ID() kan je toch wat ? Eerst record toevoegen, dan deze ID ophalen...

Kan de TS misschien wat code posten waar deze ID nodig is ?

woensdag 26 mei 2004 17:48

Acties:

woensdag 26 mei 2004 17:51

Stelt zich vragen...

Topicstarter

cameodski schreef op 26 mei 2004 @ 17:40:
[...]

En wat maakt het uit als ze zijn verwijderd? Je kunt toch op beide tabellen een COUNT (*) doen?
[...]

Neen, want in de tabel abonnees zitten ook nog een dikke 5000 oude abonnees, en er worden ook manueel nieuwe abonnees toegevoegd die zich via snailmail registreren

En uit veiligheidsoverwegingen laat ik de kandidaten in een aparte tabel (kandidaten) en mogen ze pas in de tabel met abonnees wanneer ze door een secretaris zijn nagekeken. De tabel abonenes moet namelijk strikt voor abonnees blijven, en niet voor mensen die zich via de website inschreven, maar bvb nog niet betaald hebben of nonsens invulden...

En trouwens Shadowman en LuCarD: bedankt voor die SQL code, maar ik heb er nog wat last mee. Als ik die SQL uitvoer krijg ik voor elke tabel een row, maar wanneer ik er "WHERE Name = 'kandidaten';" achter plak, krijg ik een error...

[ Voor 28% gewijzigd door Joske Pauwels op 26-05-2004 17:51 ]

Acties:

Verwijderd

maartenba schreef op 26 mei 2004 @ 17:43:
Kan de TS misschien wat code posten waar deze ID nodig is ?

Goede vraag idd; wat wil je ermee?
Lijkt een beetje op een structuur probleempje. Gok ik.
Ik kan me namelijk niet echt een situatie voorstellen dat je het ID nodig hebt van de `nog-in-te-voegen-row`.. ?

[ Voor 31% gewijzigd door Verwijderd op 26-05-2004 17:53 ]

woensdag 26 mei 2004 17:52

Acties:

woensdag 26 mei 2004 17:53

cameodski schreef op 26 mei 2004 @ 17:40:
[...]

En wat maakt het uit als ze zijn verwijderd? Je kunt toch op beide tabellen een COUNT (*) doen?

Heb je gelijk in. Ik denk dat dit ook beter is ivm dat als er toevallig een keer een record met de hand is toegevoegd met een hoger ID dat je Auto_increment dan ook een stuk hoger staat. (Tenzij de TS gebruikers verwijdert als deze niet doorgaan naar de geaccepteerde lijst).

maartenba schreef op 26 mei 2004 @ 17:43:
Met de MySQL LAST_INSERT_ID() kan je toch wat ? Eerst record toevoegen, dan deze ID ophalen...

Met eerst een record toevoegen krijg je hele hoge getallen op het eind die helemaal niet meer kloppen.

Kan de TS misschien wat code posten waar deze ID nodig is ?

NOFI Maar is de uitleg die de TS nu heeft gegeven niet voldoende?

edit:

code:

1	SHOW TABLE STATUS LIKE 'tabelnaam'

[ Voor 5% gewijzigd door Shadowman op 26-05-2004 17:56 ]

Acties:

woensdag 26 mei 2004 17:53

Joske Pauwels schreef op 26 mei 2004 @ 17:48:
[...]

Neen, want in de tabel abonnees zitten ook nog een dikke 5000 oude abonnees, en er worden ook manueel nieuwe abonnees toegevoegd die zich via snailmail registreren

En wat als een kandidaat ipv naar de abonnee tabel te gaan, gewoon wordt verwijderd?
Dan klopt jouw teller niet meer of maakt dat niet uit?

Als ik jou was, zou ik in de abonnee tabel gewoon één of ander veld opnemen waarmee je dan kunt zien dat die is aangemeld via het internet.
Maar je moet in ieder geval niet het ID gebruiken, want dat is gewoon zeer onbetrouwbaar voor dit soort dingen.

Never underestimate the power of

Acties:

woensdag 26 mei 2004 17:56

Stelt zich vragen...

Topicstarter

Verwijderd schreef op 26 mei 2004 @ 17:51:
[...]

Goede vraag idd; wat wil je ermee?

Gewoon echo'en: dus dat aantal in mijn informatiepagina tonen.
Dus eerst het Auto_increment getal van die tabel bepalen, en dat wordt dan pakweg $kandidaten_max_id

En dan ergens een tekstje:

code:

1	Er zijn reeds <?PHP echo $kandidaten_max_id; ?> registraties via de website geweest.

Acties:

woensdag 26 mei 2004 17:59

Stelt zich vragen...

Topicstarter

cameodski schreef op 26 mei 2004 @ 17:53:
[...]

En wat als een kandidaat ipv naar de abonnee tabel te gaan, gewoon wordt verwijderd?
Dan klopt jouw teller niet meer of maakt dat niet uit?

Als ik jou was, zou ik in de abonnee tabel gewoon één of ander veld opnemen waarmee je dan kunt zien dat die is aangemeld via het internet.
Maar je moet in ieder geval niet het ID gebruiken, want dat is gewoon zeer onbetrouwbaar voor dit soort dingen.

Neen, ik wil niet dat kandidaten tussen de abonnees terechtkomen. Ik weet dat ik ze kan scheiden, maar ik vind het betrouwbaarder om de database met abonnees (die erg kostbaar is) strikt gescheiden te houden.

En het maakt inderdaad niet uit of die kandidaten nu effectief abonnee geworden zijn of niet. Dus het ID nummer is het enige dat ik moet weten van die (al dan niet lege) kandidaten-tabel

Acties:

Verwijderd

Ben ik nou helemaal achterlijk (zou kunnen natuurlijk) of is een:

code:

1	select count(*)

...wat je zoekt?

woensdag 26 mei 2004 18:00

Acties:

woensdag 26 mei 2004 18:00

Joske Pauwels schreef op 26 mei 2004 @ 17:56:
[...]

Neen, ik wil niet dat kandidaten tussen de abonnees terechtkomen. Ik weet dat ik ze kan scheiden, maar ik vind het betrouwbaarder om de database met abonnees (die erg kostbaar is) strikt gescheiden te houden.

Ik bedoelde niet dat je de kandidaten gelijk in de abonnee tabel moest zetten, maar ik noemde alleen de optie om bij een abonnee bij te houden of deze via de kandidaat tabel in de abonnee tabel is gekomen of op een andere manier.

En het maakt inderdaad niet uit of die kandidaten nu effectief abonnee geworden zijn of niet. Dus het ID nummer is het enige dat ik moet weten van die (al dan niet lege) kandidaten-tabel

Tja, als jij je bezoekers voor wilt liegen

Je zou natuurlijk ook in een aparte tabel nog een teller kunnen bijhouden, maar dat is dan waarschijnlijk ook overdreven

Verwijderd schreef op 26 mei 2004 @ 17:59:
Ben ik nou helemaal achterlijk (zou kunnen natuurlijk) of is een:

Ik denk het. Of misschien gewoon slaperig

[ Voor 11% gewijzigd door cameodski op 26-05-2004 18:01 ]

Never underestimate the power of

Acties:

woensdag 26 mei 2004 18:02

Stelt zich vragen...

Topicstarter

Verwijderd schreef op 26 mei 2004 @ 17:59:
Ben ik nou helemaal achterlijk (zou kunnen natuurlijk) of is een:
code:
1
select count(*)
...wat je zoekt?

Neen, spijtig genoeg niet. Want de tabel is immers leeg, en de reeds verwijderde entries moeten meegeteld worden.

En Shadowman: bedankt! Met die code werkt het!
Mijn probleem is dus opgelost!

En @ cameodski: het is voor intern gebruik bedoelt, dus liegen kan je dat niet noemen. Het is gewoon om een beeld te hebben van de interesse en het gebruik van de (nieuwe) website. Het is een concertvereniging die zich net gemoderniseerd heeft...

[ Voor 24% gewijzigd door Joske Pauwels op 26-05-2004 18:03 ]

Acties:

woensdag 26 mei 2004 18:04

Verwijderd schreef op 26 mei 2004 @ 17:59:
Ben ik nou helemaal achterlijk (zou kunnen natuurlijk) of is een:
code:
1
select count(*)
...wat je zoekt?

Dan zullen we maar voor het eerste gaan

.

In de tabel kandidaten worden records van kandidaten die echt abonnee zijn geworden in feite verplaatst naar de tabel abonnee (en verwijdert uit kandidaten). (En valse aanmeldingen via de website worden ook verwijdert.

[ Voor 17% gewijzigd door Shadowman op 26-05-2004 18:03 . Reden: * langzaam is met replyen :/ * ]

Acties:

woensdag 26 mei 2004 18:08

Stelt zich vragen...

Topicstarter

Ik had hem gezien hoor

Tnx!

Acties:

Verwijderd

/me gaat toch heel zelfverzekerd tegenspreken dat hij datgene is wat hij sarcastisch opperde in zijn post.

Deze hele kwestie heeft ontzettend te maken met normalisatie en je database (table) structu(u)r(en).

Zoals cameodski prima zei, neem in een extra veld op hoe de persoon in de database is gekomen, dát lijkt me de oplossing.

Maar daar heeft Ivy verder niets mee te maken, succes verder!

/einde tegenspraak-modus

_{edit:

Gelukkig sta ik niet alleen, cameodski staat aan zijn navolgende post te zien aan mijn zijde...}

[ Voor 12% gewijzigd door Verwijderd op 26-05-2004 18:10 ]

woensdag 26 mei 2004 18:09

Acties:

woensdag 26 mei 2004 18:21

Joske Pauwels schreef op 26 mei 2004 @ 18:00:
[...]
En @ cameodski: het is voor intern gebruik bedoelt, dus liegen kan je dat niet noemen. Het is gewoon om een beeld te hebben van de interesse en het gebruik van de (nieuwe) website. Het is een concertvereniging die zich net gemoderniseerd heeft...

Aha, dus je houdt jezelf voor de gek

Er komen nogal eens topics langs waar mensen allerlei logica aan een auto increment koppelen en ongeveer even vaak is het een verkeerde keuze. Vandaar dat ik misschien een beetje te negatief doe. $_/-\o_$

Never underestimate the power of

Acties:

woensdag 26 mei 2004 18:37

Stelt zich vragen...

Topicstarter

cameodski schreef op 26 mei 2004 @ 18:09:
[...]

Aha, dus je houdt jezelf voor de gek

Er komen nogal eens topics langs waar mensen allerlei logica aan een auto increment koppelen en ongeveer even vaak is het een verkeerde keuze. Vandaar dat ik misschien een beetje te negatief doe. $_/-\o_$

No prob hoor

Het getal moet ook niet zo nauwkeurig zijn: er zijn vrij veel online registraties, en het percentage van bogus-registraties is bijna nihil. Dus als er pakweg 2 op de honderd kandidaten geen abonnee worden, en verwijderd worden, is dat geen ramp. Het getal is eerder een indicatie voor ons over de populariteit van de online-registraties. Er wordt namelijk ook bijgehouden hoeveel nieuwe abonnees er zij sinds dit nieuwe systeem. Zo kan gekeken worden hoeveel ervan (ongeveer) online registreerden.

Maar ik zet ze liever niet samen in één tabel omdat ik niet het risico wil lopen dat die ene bogus-registratie als een abonnee aanzien wordt. Er zijn ook aanzienlijke verschillen tussen een kandidaat en een abonnee: een kandidaat kan in een veld een voorkeur opgeven van hoe zijn vaste plaatsen moeten zijn. Abonnees hebben daarentegen vaste plaatsen gekoppeld aan hun abonnee nummer. Ik heb scripts die heel het zaalplan (5000+ plaatsen!) tekenen, en daarop alle abonnees weergeven. Het biedt dus niet echt voordelen om de kandidaten tussen de abonnees te plaatsen.

[ Voor 11% gewijzigd door Joske Pauwels op 26-05-2004 18:23 ]

Acties:

woensdag 26 mei 2004 18:39

Joske Pauwels schreef op 26 mei 2004 @ 18:21:

Ik heb eerlijk gezegd het vermoeden dat er wordt bedoeld dat als er kandidaten naar de tabel Abonnees worden verplaatst dat er dan in die tabel een veld is waarin wordt aangegeven dat de registratie via het internet is gegaan.

Acties:

woensdag 26 mei 2004 19:15

Stelt zich vragen...

Topicstarter

Dat heb ik overwogen, maar de database zou dan nog groter worden (zo'n extra kolom doet mss niet veel, maar bij zoveel entries begint dat toch al uit te maken), en het getal is niet zo enorm belangrijk, en mag er dus gerust een beetje naast zitten... En er staat ook duidelijk dat er zoveel mensen zich via het internet inschreven, dus niet dat ze ook abonnee geworden zijn.

De oplossing die ik nu heb voldoet dus prima aan de noden. Het is gewoon een indicatief getal waaruit afgeleid kan worden of de online regestratie al dan niet populair is...

[ Voor 14% gewijzigd door Joske Pauwels op 26-05-2004 18:40 ]

Acties:

Verwijderd

Joske Pauwels schreef op 26 mei 2004 @ 18:39:
(zo'n extra kolom doet mss niet veel, maar bij zoveel entries begint dat toch al uit te maken)

[mierenn*ukmodus]
wil ik toch stiekem een beetje tegenspreken.
[/mierenn*ukmodus]

Al met al snap ik wel heel goed dat je het zo oplost, aangezien het geen ontzettend belangrijk gegeven is wat je weer gaat geven.

Succes verder, klinkt als een leuk project.

woensdag 26 mei 2004 20:54

Acties: