[PHP/MySQL] Probleem met updaten van dbase.

[Tijgertje84]

We gebruiken een programma waarmee wij tickets kunnen aanmaken.
Na het aanmaken van een ticket worden de gegevens ingevult in de database en vevolgens wordt er een mail gestuurt naar de admin met een ticketnummer.
Dit werkt perfect, alleen gaat het op een gegevens moment mis.
Na de 1000 tickets kwamen de problemen.

PHP:

//Creates the ticket mask
        $insertedId = mysql_insert_id();
        $ticketmask = rand(1000,9999).$insertedId.rand(10,99);
        $query = "UPDATE #__support_ticket SET ticketmask='$ticketmask' WHERE id='$insertedId'";
        $database->setQuery( $query );
        $database->query();

hierboven het gedeelte van de bron waar de ticketmask word ingevoerd in de dbase.
als er een nieuw ticket word gemaakt word er hetvolgende gemaakt:
(eerst een random getal van 4 gegenereerd + de inserted_id(dit is de positie in de database) + 2 random getallen)
Dit programma is door iemand geschreven die we op dit moment niet kunnen bereiken. En dit is al 2 dagen zo, maar we kunnen niet lang meer wachten want dit betreft een zeer belangrijke handeling.

Het heeft altijd goed gewerkt!!!!!!
Bij het aanmaken van de 1001ste ticket gaat het mis......
Dit is het nummer wat elke keer voor elke nieuwe ticket in de dbase wordt gezet: 2147483647.
Terwijl het in de email bij de administrator wel goed aankomt als: 1682100169 (4 random getallen + id + 2 random getallen)

Als je dit leest klopt het al niet aangezien we nog helemaal geen 4836 records hebben....
als we een 1002 aan gaan maken dat klopt het mail weer wel maar wordt tevens weer hetzelfde ticketmask in de dbase gezet namelijk: 2147483647

Weet iemand hoe het komt dat dit opeens na de 1000 tickets mis gaat.

[NMe]

Laat me raden: het type van het veld in je database is signed int? Maak daar bigint van en het werkt weer even. Nadruk op even overigens, want ik heb de indruk dat deze manier van genereren ook niet lang goed gaat. Als je iets unieks moet genereren kun je beter iets doen met de datum of iets dergelijks, en een volgnummer.

Desnoods gebruik je een string. Ook kun je denken aan hashen.

Even Googlen had ook veel duidelijk gemaakt... [google=mysql 2147483647]

[ Voor 21% gewijzigd door NMe op 13-09-2005 14:55 ]

[Tijgertje84]

-NMe- schreef op dinsdag 13 september 2005 @ 14:53:
Laat me raden: het type van het veld in je database is signed int? Maak daar bigint van en het werkt weer even. Nadruk op even overigens, want ik heb de indruk dat deze manier van genereren ook niet lang goed gaat. Als je iets unieks moet genereren kun je beter iets doen met de datum of iets dergelijks, en een volgnummer.

Desnoods gebruik je een string. Ook kun je denken aan hashen.

Even Googlen had ook veel duidelijk gemaakt... [google=mysql 2147483647]

Nou kijk de random getallen zijn niet zozeer bepalend want het id wordt in de de ticketmask gegenereerd. Deze ticketmask is belangrijk. De id in de tabel niet, deze word alleen gebruikt in de ticketmask om er een unieke code van te maken. Dus het is al uniek alleen is de rest van de id beetje rommelig imo (random geen goede optie geweest van ontwikkelaar imo..)
Vraag me niet waarom die gast het zo heeft gemaakt, maar hij zit nu in Portugal en heb dus zeer weinig aan hem...

Maar het probleem was idd die BIGINT !!! Ik had zelf geen acces in de dbase maar nadat ik samen met de admin ernaar keek zag ik idd er INT staan ipv BIGINT.
Ben zelf nog steeds bezig met PHP leren met boek dus ben nog niet zow heel erg ver maar dit vergeet ik zeker niet meer
Hartstikke bedankt

[Solopher]

Om eerlijk te zijn heb ik dit probleem ook wel eens gehad :]

Mogelijk een veel voorkomende fout.

[T-MOB]

-NMe- schreef op dinsdag 13 september 2005 @ 14:53:
Nadruk op even overigens, want ik heb de indruk dat deze manier van genereren ook niet lang goed gaat. Als je iets unieks moet genereren kun je beter iets doen met de datum of iets dergelijks, en een volgnummer.

Mwoah.. een bigint gaat unsigned tot 9223372036854775807, dan kunnen er dus sowieso nog een paar miljard van deze hashes in de DB (mits MySQL het volhoudt )

[twiekert]

Beetje wazig die lange ticketmask . Waarschijnlijk om het ticketnummer/casenummer een profi uiterlijk te geven. Kan je beter doen door het ID nummer bij een vast random getal op te tellen, iets als 125442 + ID. Die 125442 sla je uiteraard vast op in de code als variabele.

Moet je er wel voor zorgen dat je ID nooit wijzigt natuurlijk.

[NMe]

T-MOB schreef op dinsdag 13 september 2005 @ 22:39:
Mwoah.. een bigint gaat unsigned tot 9223372036854775807, dan kunnen er dus sowieso nog een paar miljard van deze hashes in de DB (mits MySQL het volhoudt )

Eindig is eindig. Maar je hebt inderdaad gelijk dat dit voorlopig nog wel voldoet, ik schatte de maximale waarde van een bigint even wat te laag in.

twiekert schreef op dinsdag 13 september 2005 @ 22:44:
Beetje wazig die lange ticketmask . Waarschijnlijk om het ticketnummer/casenummer een profi uiterlijk te geven. Kan je beter doen door het ID nummer bij een vast random getal op te tellen, iets als 125442 + ID. Die 125442 sla je uiteraard vast op in de code als variabele.

Moet je er wel voor zorgen dat je ID nooit wijzigt natuurlijk.

Ik denk juist dat het de bedoeling is dat die ticketnummers niet opeenvolgend zijn. En als dat zo is, dan zou ik dus eerder voor een hash gaan.

[Tijgertje84]

solopher schreef op dinsdag 13 september 2005 @ 22:19:
Om eerlijk te zijn heb ik dit probleem ook wel eens gehad :]

Mogelijk een veel voorkomende fout.

twiekert schreef op dinsdag 13 september 2005 @ 22:44:
Beetje wazig die lange ticketmask . Waarschijnlijk om het ticketnummer/casenummer een profi uiterlijk te geven. Kan je beter doen door het ID nummer bij een vast random getal op te tellen, iets als 125442 + ID. Die 125442 sla je uiteraard vast op in de code als variabele.

Moet je er wel voor zorgen dat je ID nooit wijzigt natuurlijk.

Dit is niet goed want nu maak je het nummer NIET uniek!
Stel je maakt een nieuw ticket aan met ID 1020 + random getal 125442 = 126462
En over een tijdje maak je een ticket aan met ID 5002 + random getal 121460= 126462
Hetzelfde De kans dat er ooit een zelfde ticketmask gemaakt wordt is er dus en dat is dus niet de bedoeling
De maniet zoals het nu gedaan wordt is wel uniek omdat elke ticketmask een apart id heeft binnen de mask.
Maar zoals ik al eerder zei heb ik dit niet geschreven en valt dit ticketmask verhaal op meerdere manieren op te lossen
Waarom de getallen rond de ID random moeten zijn??? Geen id je kan gewoon net zogoed een standaard id laten aanmaken met de 1ste bv 1000000001 en dan 1000000002 etc etc
Komt volgens mij op het zelfde neer en heeft imo meer mogelijke combinaties als met die random..

-NMe- schreef op dinsdag 13 september 2005 @ 22:53:
Ik denk juist dat het de bedoeling is dat die ticketnummers niet opeenvolgend zijn. En als dat zo is, dan zou ik dus eerder voor een hash gaan.

Nu weet ik alleen niet wat er bedoeld wordt met hash

[ Voor 10% gewijzigd door Tijgertje84 op 14-09-2005 09:03 ]

[Nick The Heazk]

/me Heazk vind het hele gedoe met random getallen maar vreemd

Waarom gebruik je gaan md5 of sha1 versleuteling?

Een hash maakt van een string of integer een unieke string (in md5's en sha1's geval) van 32 karakters. Deze hash is steeds uniek. Tenzij je tweemaal dezelfde string hashed.

vb.

'akbj' -> 'zegh435sg1hb354df3d23sf1v3sdfb351' (ik zeg maar wat)
'361jb' -> '354bsgvsdfszdvds5h4dhs231df3bv4fh'
'akbj' -> 'zegh435sg1hb354df3d23sf1v3sdfb351'

Merk op dat bij het hashen van dezelfde string, je ook dezelfde hash uitkomt. Ideaal voor validatie van wachtwoorden.

[ Voor 87% gewijzigd door Nick The Heazk op 14-09-2005 09:30 ]

[T-MOB]

Nick The Heazk schreef op woensdag 14 september 2005 @ 09:26:
/me Heazk vind het hele gedoe met random getallen maar vreemd

Waarom gebruik je gaan md5 of sha1 versleuteling?

Een hash maakt van een string of integer een unieke string (in md5's en sha1's geval) van 32 karakters. Deze hash is steeds uniek. Tenzij je tweemaal dezelfde string hashed.

Eigenlijk is een hash geen versleuteling... Een hashingsalgorithme is een transformatie van de input met als uitkomst de zgn hash. Bij een goed hashingsalgorithme is die hash niet terug te rekenen naar de input, wat bij versleutelen afaik wel het geval is
Een hash is per definitie niet uniek... In het geval van MD5 heb je 128-bits hashes en dus maximaal 2¹²⁸ verschillende uitkomsten op een oneindig grote hoeveelheid mogelijk input. Wanneer je hashes gebruikt om 'unieke' codes te genereren moet je dus altijd checken of je nieuw gegenereerde code niet al bestaat. Tel daarbij op dat TS prima mogelijkheden heeft om zo al een unieke code te genereren (het ID is immers uniek) en het hashen maakt het alleen maar complexer...

* T-MOB vindt het "gedoe" met de random getallen wel meevallen

[Brons]

Het kan zijn dat ik iets gemist heb, maar als je gewoon het ID gebruikt dat mysql maakt komt het toch helemaal goed? Het is dan altijd uniek.

[NMe]

Tijgertje84 schreef op woensdag 14 september 2005 @ 09:01:
Nu weet ik alleen niet wat er bedoeld wordt met hash

Dan kun je toch een beetje creatief Googlen?
http://en.wikipedia.org/wiki/Hash_function

[Tijgertje84]

Brons schreef op woensdag 14 september 2005 @ 13:31:
Het kan zijn dat ik iets gemist heb, maar als je gewoon het ID gebruikt dat mysql maakt komt het toch helemaal goed? Het is dan altijd uniek.

Jup is ook zo maar jah weet ook niet waarom die gast eht zo heeft gedaan....

[twiekert]

Tijgertje84 schreef op woensdag 14 september 2005 @ 09:01:
[...]


[...]

Dit is niet goed want nu maak je het nummer NIET uniek!
Stel je maakt een nieuw ticket aan met ID 1020 + random getal 125442 = 126462
En over een tijdje maak je een ticket aan met ID 5002 + random getal 121460= 126462
Hetzelfde

Je moet ook maar 1X 'at random' het basisgetal van een case bepalen. Dus het basisgetal wordt altijd 125442. dit sla je op als constante in je programma, niet in de database.

als je een case weergeeft op scherm/papier/whatever doe dan het ID nummer van de case (wat dus altijd uniek is) + het basisgetal als constante = 125442 + ID.

Mocht je case nummers niet opeenvolgend willen hebben dan zal je random een nummer moeten genereren wat niet voorkomt in de database. En dan natuurlijk niet een nummer wat zo ongelooflijk lang is dat het niet meer in een INT past