[MySQL and or PHP] Unieke ID voor transacties

[hobbit_be]

Ik ben bezig met een project waar ik bepaalde transacties heb. (ie Mail checking for marketing analysis).

Nu gebruikte ik gewoon een id die mySQL gaf maar deze zijn natuurlijk sequentieel en maakt het dus eenvoudig voor fake input te geven (niet dat dit het geval zou zijn).

Ik zoek dus naar een betere manier om een uniek "ID" te geven die niet zo voorspelbaar is. Ik dacht dus aan een GUID maar daar vidn ik bijna niets over ivm PHP (wel een paar die het faken)

ook heeft PHP een uniqid maar ook deze lijkt me volledig voorspelbaar. Ze raden aan deze dan de MD5 - en maar dit is een hash dus duplicates zijn niet uit te sluiten.

Ook vraag ik me af hoe snel mySQL het dan gaat vinden om de update (ie transactie voltooien) in zijn tabel. We spreken hier over 30.000 - > 100.000 records. Om deze tabel dan te indexen lijkt me ook pijnlijk. (ie Index op 32chars bijvoorbeeld). Om het uniek te maken zou ik de laatse 8 chars weer als een mySQL laatste insert_id zetten.

Iemand meer ervaring hiermee?

[ATS]

Ik zat zelf ook te denken aan een MD5 hash, maar het ligt nogal aan je gebruik van de database. Op zich is een index over 10^5 records geen enkel probleem, maar als je heel veel records invoegt dan kost het wel tijd (het scheelt daar en tegen heel erg veel tijd bij het weer opzoeken).

Als je niet al te veel inserts tegelijk doet of de data regelmatig weer nodig hebt, dan zou ik toch eens kijken naar zo'n hash. Je kan via een index zowiezo aangeven dat een veld uniek moet zijn, dus kan je het (zeldzame!) geval dat je een dubbele ID zou genereren afvangen.

Anders kan je altijd nog kijken of je zelf aan die hash nog wat toe kan voegen, zoals een eenvoudig ge-encode versie van je volgnummer. Zoiets als:

PHP:

$ID=MD5("foobar".$volgnummer).baseconvert($volgnummer,10,36)

Hier zorgt de baseconvert ervoor dat je ID in elk geval uniek is, terwijl de MD5 ervoor zorgt dat hij lastig te raden zal zijn.

[bigtree]

hobbit_be schreef op 03 december 2003 @ 10:34:
ook heeft PHP een uniqid maar ook deze lijkt me volledig voorspelbaar. Ze raden aan deze dan de MD5 - en maar dit is een hash dus duplicates zijn niet uit te sluiten.

Duplicaties zijn bij GUID ook niet uit te sluiten, aangezien hun eindige lengte. Nuttige link: http://www.guid.org/

[hobbit_be]

ATS schreef op 03 december 2003 @ 11:21:
Als je niet al te veel inserts tegelijk doet of de data regelmatig weer nodig hebt, dan zou ik toch eens kijken naar zo'n hash. Je kan via een index zowiezo aangeven dat een veld uniek moet zijn, dus kan je het (zeldzame!) geval dat je een dubbele ID zou genereren afvangen.

tja helaas is dit het geval. Hij zou voor een periode van een uur constant niets anders doen dat het aanmaken van transacties (ie 10.000 ofzo). Dat het niet snel te vinden is niet echt een super issue aangezien de "confirm" van de transacties pas later en erg gespreid kunnen zijn.

[hobbit_be]

Via help van iemand hebben we besloten om ipv met transacties te werken - we gewoon een strongly encrypted data meezenden. Zodoende kan daarin gezet worden wat gedaan moet worden. Dat het dan geen transactie is is jammer maar meer manageable.