[PHP/MySQL] Systeem uitbreiden met SEO friendly URL's

[Verwijderd]

Mijn eigen website wil ik gaan omzetten naar SEO friendly URL's. Nog voordat ik met mod_rewrite aan de slag ga had ik een vraag of mijn aanpak wel goed is.

Op dit moment genereer ik voor elk nieuw record in de database een uniek id met onderstaand PHP commando:

code:

$NewID = sha1( uniqid() );

De URL van een item is dan bijvoorbeeld: www.domein.nl/show_item.p...69127135d56ab1a4c45c3189f

Nu wil ik in die tabel een extra SEO friendly veld aanmaken dat ik -als het ingevuld is- ga gebruiken i.p.v. het sha1 id veld. Dat extra veld mag alleen uit letters, cijfers en een streepje bestaan, en moet uniek zijn. Stel, ik vul daar voor een bepaald product 'kleine-fiets' in.

Ik wou in mijn PHP dan zoiets als de volgende code gebruiken om de link te maken:

code:

if ( strlen(trim($row[seofriendlyfield])) ) $link=$row[seofriendlyfield]; else $link=$row[item_id];

De link naar het item wordt dan: www.domein.nl/show_item.php?id=kleine-fiets

Is het een goede manier om het op deze manier aan te pakken?

[ Voor 4% gewijzigd door Verwijderd op 21-01-2013 17:47 ]

[Gtoniser]

Kan. Je moet dan wel de volledige url afvangen in PHP en in de database checken of deze bestaat voordat je weet wat het nieuwsitem is dat wordt opgevraagd.
Je kunt ook gewoon de url bijvoorbeeld:

code:

www.domein.nl/kleine-fiets_69127135d56ab1a4c45c3189f.html

gebruiken, en dan dat laatste stukje met rewrite laten rewriten tot

code:

www.domein.nl/show_item.php?id=69127135d56ab1a4c45c3189f

Sowieso zou ik voor wat kortere ID's zijn gegaan (5 of 6 tekens is meer dan zat)

[ Voor 8% gewijzigd door Gtoniser op 21-01-2013 17:50 ]

[RobIII]

Gtoniser schreef op maandag 21 januari 2013 @ 17:48:
Kan. Je moet dan wel de volledige url afvangen in PHP en in de database checken of deze bestaat voordat je weet wat het nieuwsitem is dat wordt opgevraagd.

En hoe is dat anders voor een ID Als je op de "slug" (ook) een index (met unique constraint) zet kost 't evenveel.

Het nut van SHA1 en uniqid ontgaat me echter (sowieso is de combinatie van die twee een verhaal apart met entropie enzo); een autonumbering ID volstaat in de meeste gevallen tenzij je niet wil dat men (bijv. door de oplopende eigenschap) ID's kan gaan zitten raden.

[ Voor 6% gewijzigd door RobIII op 21-01-2013 18:32 ]

[Gtoniser]

RobIII schreef op maandag 21 januari 2013 @ 18:32:
[...]
En hoe is dat anders voor een ID Als je op de "slug" (ook) een index (met unique constraint) zet kost 't evenveel.

Ja en nee. Als je het ID ook in de url zet dan hoef je het voor SEO en non-SEO maar 1x op te zoeken en kan het met een simpele rewrite url herschreven worden naar het oude systeem.
Daarnaast zou de friendly URL kunnen veranderen van een item, als je een ID in de URL hebt staan dan kom je altijd weer bij het juiste item terecht (evt met een redirect naar de nieuwe URL).

[Verwijderd]

@ Gtoniser: Dank je!

@ RobIII: Autonummering zou in de meeste gevallen kunnen volstaan, echter bij mij niet in dit geval.

Dat sha1 staat gewoon als voorbeeld op de eerste pagina van php.net. Net als met md5 er omheen. Nooit een probleem mee gehad.

[ Voor 81% gewijzigd door Verwijderd op 23-01-2013 19:33 ]

[rednek]

wacht autoincrement met een primary key geeft jouw problemen? in wat opzicht, bijna de hele wereld gebruikt dit voor websites.

Wat je ook kan doen is een id converten naar een string door bijvoorbeeld deze functie te gebruiken.

<php>
/**
* Converts an integer into the alphabet base (A-Z).
*
* @param int $n This is the number to convert.
* @return string The converted number.
* @author Theriault
*
*/
function num2alpha($n) {
$r = '';
for ($i = 1; $n >= 0 && $i < 10; $i++) {
$r = chr(0x41 + ($n % pow(26, $i) / pow(26, $i - 1))) . $r;
$n -= pow(26, $i);
}
return $r;
}
</php>

[Verwijderd]

@ rednek: Stel, je hebt 2 id's:
id1 = 123444556789
id2 = 445
Ik weet het niet meer zeker wat bij mij precies het probleem was (is al wat jaren geleden) maar zo uit het hoofd ging het mis dat hij dan id2 vond terwijl ik id1 bedoelde als ik een winkelmand string (met daarin id, optie maat en optie kleur) doorspeurde. Plus het probleem van id's raden. En waarom moeilijk doen als het op een andere manier allemaal geen problemen geeft? Dus vandaar.

Ja die functie is wel handig. maar werkt alleen bij alleen maar nummers (autonummering). Ik kwam ook nog een andere functie tegen van ene van Zonneveld die een soort Youtube achtige IDs maakte, ook mooi (wel een beetje lange functie) maar werkte ook alleen met getallen oftewel autonummering.

Het is wel leerzaam dit trouwens al die antwoorden en opmerkingen. Dank.

[ Voor 24% gewijzigd door Verwijderd op 23-01-2013 19:38 ]

[RobIII]

Verwijderd schreef op dinsdag 22 januari 2013 @ 11:16:
@ rednek: Stel, je hebt 2 id's:
id1 = 123444556789
id2 = 445
Ik weet het niet meer zeker wat bij mij precies het probleem was (is al wat jaren geleden) maar zo uit het hoofd ging het mis dat hij dan id2 vond terwijl ik id1 bedoelde als ik een string doorspeurde. Maar dat zal ongetwijfeld aan mijn (verkeerde) aanpak gelegen hebben. Ik had in elk geval geen problemen als de id's altijd even lang waren (zelfde aantal karakters). Plus het 'probleem' van id's raden. En waarom moeilijk doen als het op een andere manier allemaal geen problemen geeft? Dus vandaar.

Ik ruik een ma-jor WTF hier... Ik wil je (echt niet) afvallen, maar wat je hier post getuigt wel van een enorm gat aan kennis. Ik ga 't aan andere posters over laten om uit te leggen wat er mankeert allemaal (ik moet weg anders had ik de tijd wel genomen), maar ik heb wel nog dit voor je: als je "mooie YouTube ID's" wil kun je net zo goed een autonummering int gebruiken. Die haal je vervolgens door base_convert et voila. Niks lange functies:

PHP:

echo base_convert(12345678, 10, 36); // int -> YT-id
echo base_convert('7clzi', 36, 10);  // YT-id -> int

7clzi
12345678

Overigens kent MySQL ook een conv() functie:

MySQL:

-- YT-id -> record-id
select `foo`, `bar` from `mytable` where `id` = conv('7CLZI', 36, 10);

-- records ophalen met id én YT-id
select `id`, conv(`id`, 10, 36) as `ytid`, `foo`, `bar` from `mytable` where ...

[ Voor 56% gewijzigd door RobIII op 23-01-2013 14:10 ]

[Verwijderd]

Een enorm gat aan kennis zal wel meevallen. Misschien was het niet nodig omdat het gewoon goed werkte met een UUID?

[ Voor 145% gewijzigd door Verwijderd op 23-01-2013 20:39 ]

[Rob]

Ik verbaas mij er al over dat je het over strings hebt bij een ID.
Gebruik je autonummering, dan gebruik je getallen

[Verwijderd]

Ik gebruik juist geen autonummering en dat wil ik ook niet gebruiken.

//edit: O okee, a.d.h.v. van mijn voorbeeld dan. Die string was opgebouwd uit het id van het product en de gekozen kleur en gekozen maat. Om de juiste producten met juiste opties in een winkelmand te krijgen. Het was zo maar een voorbeeld en is al jaren geleden dus misschien was het wel totaal iets anders.

[ Voor 69% gewijzigd door Verwijderd op 22-01-2013 13:08 ]

[Rob]

Waarom wil je geen autonummering gebruiken? Dan laat je de "uniekheid" van het ID namelijk afhangen van de databaseserver en niet van php.
Stel je hebt 2 php workers en hun klokken staan niet helemaal gelijk, dan is er een kans dat ze allebei hetzelde ID creeeren bij het gebruik van uniqid

[Verwijderd]

Ja, daar begon RobIII ook al over maar ik heb er zoals gezegd in het verleden problemen mee ondervonden, met autonummering. Ik heb dat er toen voor een aantal sites uit moeten slopen en met vervangen door uniqid's werkte dat toen wel vlekkeloos.

Maar wat je zegt daar is niets tussen te krijgen natuurlijk. Maar er is maar 1 persoon die werkt aan de website.

[ Voor 48% gewijzigd door Verwijderd op 23-01-2013 20:41 ]

[OkkE]

Verwijderd schreef op dinsdag 22 januari 2013 @ 11:16:
@ rednek: Stel, je hebt 2 id's:
id1 = 123444556789
id2 = 445
Ik weet het niet meer zeker wat bij mij precies het probleem was (is al wat jaren geleden) maar zo uit het hoofd ging het mis dat hij dan id2 vond terwijl ik id1 bedoelde als ik een string doorspeurde.

Dit klinkt als een

code:

SELECT [...] WHERE ID = "%id%"

in de query?

---

Anyway; het idee is simpel gezegd om in je database een slug (is unieke string) te koppelen aan je unieke ID. In dat opzicht lijkt me het idee uit de topic start OK.
De nieuwe URL kun je dan weer omzetten zodat "?show_item.php?id=..." verdwijnt.

[ Voor 9% gewijzigd door OkkE op 22-01-2013 14:02 ]

[Guillome]

Je bent koppig Je luistert niet naar de adviezen van mensen die er veel van weten en denkt het zelf beter te weten? Terwijl dit een basisprincipe is wat de hele wereld gebruikt?

Je moet niet zelf je eigen ID`s gaan onderhouden tenzij je heel goed weet waarom en wat je doet. En dat weet jij niet (nofi).

Ik gebruik voor mijn sites hetvolgende:
Uiteraard gewoon AutoInc Id`s.
Hij vertaalt de (verplichte) titel in inderdaad [letters|cijfers|-].tolowercase en zet dat in de database alszijnde: systemname.

De url is dan: site.nl/products/product-titel

Op systemname zit een index en is uniek en wordt op gezocht

[ Voor 5% gewijzigd door Guillome op 23-01-2013 13:47 ]

[Gomez12]

Verwijderd schreef op dinsdag 22 januari 2013 @ 13:11:
Ja, daar begon RobIII ook al over maar ik heb er zoals gezegd in het verleden problemen mee ondervonden, met autonummering. Ik heb dat er toen voor een aantal sites uit moeten slopen en met vervangen door uniqid's werkte dat toen wel vlekkeloos.

Maar wat je zegt daar is niets tussen te krijgen natuurlijk. Wellicht dat ik het voor een volgend projectje dan maar weer eens ga proberen met de autonummering.

Kijk dan bij een volgend project wel even de handleiding door.

Zoals ik het nu lees heb je gewoon niets gesnapt van autonummering en heb je het daarom compleet verkeerd gebruikt. En is het feit uniqids wel werken eerder toeval dan bewust gepland.

[Verwijderd]

Dank jullie, Okke en Guilome. Ik ga ermee aan de slag!

Gomez12: Houden we 't een beetje beleefd hier?

[ Voor 28% gewijzigd door RobIII op 23-01-2013 14:31 ]

[Struikrover]

Wat veel frameworks gebruiken is een zogenaamd 'single point of entry', oftewel het index.php bestand waar alles binnen komt. Zo te zien heb jij dat ook.

Via mod_rewrite vang je dus de variabele af, zodat deze wordt doorgestuurd naar index.php als GET.

Wanneer jouw records een titel hebben, zou je deze ook uniek kunnen maken in de database. Als dat geen mogelijkheid is ben je aangewezen op de huidige variabele die de URL uniek maakt (misschien je identifier dus).

In je index.php dien je dan alleen nog de variabele die is binnen gekomen te escapen (belangrijk, want het is user input!) en te matchen met het ID of de titel in de database van een record.

We weten verder niks over de implementatie van jouw website (zelfgemaakt systeem?) dus daar kunnen we verder geen advies over geven.

[kwaakvaak_v2]

Ach... soms is het gebruik van een UUID nog niet eens zo onhandig hoor. Gebruik het wel eens voor settings of transactie • data. (en ja die staat soms in de DB) Dan is het wel zo handig dat je DB niet autoincrements gebruikt zodat je met een gerust hart 2 tabellen met settings kunt mergen ofzo.

In principe doet mongoDB dit onder water ook, zorgt er voor dat je 'offline' documents kunt toevoegen en deze later te mergen in je master zonder rare problemen


Of zoals de TS voor product nummers. Een SKU is ook niet altijd een opvolgend nummertje, maar eerder een samengestelde string. Wil je dat netjes mappen in een applicatie is het het makkelijkste om gewoon een mapping tabel te maken die je slug mapped op je interne ID. Kun je mooie fancy url's maken, zonder van die rare getal reeksen te gebruiken. Kost je wel 1 query per hit extra of je moet ze heel stoer cachen in APC als het er geen 10.000'en zijn.

• ik meen ooit vroeger in de tabel definitie van exact globe enterprise gezien te hebben dat voor elke boeking een UUID (v3) werd gebruikt ipv een auto inc. ID.

[Gomez12]

kwaakvaak_v2 schreef op woensdag 23 januari 2013 @ 15:53:
Ach... soms is het gebruik van een UUID nog niet eens zo onhandig hoor.

Enkel is een UUID iets heel anders dan de sha1 van een UUID. Een UUID heeft als eigenschap dat deze uniek is, op het moment dat je die gaat hashen (zeker met die korte input waardes) heb je een redelijk grote kans op collisions.

En sowieso wil je een UUID in je db laten genereren en niet in je app.

En daarnaast wil je bijna nooit rechtstreeks sha1 / hashes aanroepen, maar tegenwoordig bijna altijd enkel maar framework-calls / function calls die het gewoon onderhuids regelen en gelijk allerlei andere methodes toepassen etc.

Maar je moet wel een heel gegronde reden hebben wil je uuid gaan gebruiken ipv een simpele auto-inc, want het is qua indexes / benaderen ongeveer tig keer zo zwaar voor je db.

En tja, verkeerd gebruik van auto-inc velden waardoor die niet werken vind ik nou niet echt een super-reden zeg maar.

[ Voor 5% gewijzigd door Gomez12 op 23-01-2013 17:07 ]

[kwaakvaak_v2]

Gomez12 schreef op woensdag 23 januari 2013 @ 17:07:
[...]

Enkel is een UUID iets heel anders dan de sha1 van een UUID. Een UUID heeft als eigenschap dat deze uniek is, op het moment dat je die gaat hashen (zeker met die korte input waardes) heb je een redelijk grote kans op collisions.

En sowieso wil je een UUID in je db laten genereren en niet in je app.

En daarnaast wil je bijna nooit rechtstreeks sha1 / hashes aanroepen, maar tegenwoordig bijna altijd enkel maar framework-calls / function calls die het gewoon onderhuids regelen en gelijk allerlei andere methodes toepassen etc.

En hoe denk je dat die onderhuidse functies de data mappen dan? Je zult toch ergens een vertaling van UUID -> Gegevens moeten doen. En of je dat nu zelf direct doet, of door een framework af laat handelen maakt niet zo bijzonder veel uit

Maar je moet wel een heel gegronde reden hebben wil je uuid gaan gebruiken ipv een simpele auto-inc, want het is qua indexes / benaderen ongeveer tig keer zo zwaar voor je db.

Tenzij je database native UUID support voor heeft, dan valt het weer reuze mee. Volgens mij maakt het voor SQL-Server van Microsoft bijv. niet zo gek veel uit of je een ID gebruikt of een UUID.

[RobIII]

kwaakvaak_v2 schreef op woensdag 23 januari 2013 @ 17:20:
Tenzij je database native UUID support voor heeft, dan valt het weer reuze mee. Volgens mij maakt het voor SQL-Server van Microsoft bijv. niet zo gek veel uit of je een ID gebruikt of een UUID.

Nou, met een boel mitsen-en-maren... Zo is een PK (waar je vaak de autoincrementing id zou gebruiken) vaak een clustered index. Bij 't inserten van een UUID/GUID is deze actie dan dus duurder omdat deze niet opeenlopend zijn (sterker: bij elke insert veroorzaak je bijna geheid een dirty page). Ook past er veel minder data in een page omdat de "ID's" achterlijk groot zijn (16(+?) vs 4 bytes ofzo, en dat zonder goede reden) waardoor er dus minder efficiënt van 't geheugen gebruik gemaakt kan worden en je dus eerder I/O zult krijgen enz. enz. enz. En dat is nog los van 't feit dat 't gewoon ruk debugged met dergelijke grote ID's (laat staan sha1-hashes e.d.).

edit:
Zie bijvoorbeeld hier (meer hier) waar o.a. deze argumenten (en meer) aangehaald worden. Ik blijf erbij: zolang er geen goede reden voor is GUID's/UUID's te gebruiken blijf je lekker bij auto-inc (big)intjes

[ Voor 16% gewijzigd door RobIII op 23-01-2013 19:28 ]

[Verwijderd]

Ach... soms is het gebruik van een UUID nog niet eens zo onhandig hoor.

Inderdaad. Ik snap al die hysterie daarover hier nu niet zo, en de bijbehorende aanvallen/verwijten/vooroordelen aan mijn adres...

UUID gebruik ik al sinds 1998, toen met ColdFusion. Dat kwam nota bene 1 op 1 uit de meegeleverde voorbeeldapplicaties (o.a. een complete webshop) van de makers van ColdFusion zelf, Allaire (later Macromedia en later Adobe). Nooit 1 probleem mee ondervonden, tot op de dag van vandaag.

En met PHP uniqid() een md5 of sha1 er omheen zetten wordt ook vaak gebruikt. Het staat gewoon op de eerste pagina van php.net. Met md5 erom krijg je 32 tekens en met sha1 erom 40 tekens. Handig voor het geven van een unieke naam aan een upgeload plaatje. Komt op veel grote sites voor, je kan het natuurlijk zo zien aan de naam van de plaatjes.

Overigens gebruik ik auto increment wel gewoon op andere sites.

En dan ook nog maar een voorbeeld: Bij het overzetten van 100 autogenummerde artikelen met elk 10 foto's naar een andere database gaat het mis. De 100 id's van de nieuwe artikelen bestaan al lang in de huidige database. Dus een probleem met de id's. De bijbehorende 100x10=1000 foto's van die artikelen wijzen allemaal naar de id's van die artikelen die veranderd moeten gaan worden, dus alle verwijsid's van alle 1000 foto's moeten dus ook aangepast worden. Met unieke id's had je dit probleem niet gehad.

Nou, brand me maar weer af hoor!

[ Voor 8% gewijzigd door Verwijderd op 24-01-2013 10:46 ]

[RobIII]

Verwijderd schreef op woensdag 23 januari 2013 @ 20:38:
Inderdaad. Ik snap al die hysterie daarover hier nu niet zo, en de bijbehorende aanvallen/verwijten/vooroordelen aan mijn adres...

Klik eens op wat linkjes en lees eens wat zaken uit mijn post Ik zie daar toch wel een heleboel bezwaren staan die niet/amper opwegen tegen de voordelen. Ja, er zijn scenario's waarvoor UUID/GUID's handig zijn, maar daar is in dit topic weinig over terug te vinden. Dat je dan gewezen wordt op iets dat bij veel mensen een rode vlag doet rijzen is niet vreemd; wees blij dat 't gedaan wordt. Wie weet hadden we wel wat ernstigers aan 't daglicht gebracht.

Daarbij vraag je letterlijk om feedback over je systeem:

Verwijderd schreef op maandag 21 januari 2013 @ 17:42:
Nog voordat ik met mod_rewrite aan de slag ga had ik een vraag of mijn aanpak wel goed is.

Op dit moment genereer ik voor elk nieuw record in de database een uniek id met onderstaand PHP commando:
..blablacode..
[...meer...]
Is het een goede manier om het op deze manier aan te pakken?

En dan vind je 't raar als je feedback krijgt

De wereld vergaat niet hoor, maar GUID/UUID's zijn niet de meest voor de hand liggende keuze in veruit de meeste gevallen. Daarbij: de "ma-jor WTF" was specifiek gericht op:

Verwijderd schreef op dinsdag 22 januari 2013 @ 11:16:
@ rednek: Stel, je hebt 2 id's:
id1 = 123444556789
id2 = 445
Ik weet het niet meer zeker wat bij mij precies het probleem was (is al wat jaren geleden) maar zo uit het hoofd ging het mis dat hij dan id2 vond terwijl ik id1 bedoelde als ik een winkelmand string (met daarin id, optie maat en optie kleur) doorspeurde.

Dat betekent dat je een ...where `id` like '%445%'... moet hebben gedaan. a) Een like doe je op een varchar/text/... en niet op een int, b) een like is sowieso de verkeerde operator ( = was hier de juiste keuze geweest).

Verwijderd schreef op woensdag 23 januari 2013 @ 20:38:
En met PHP uniqid() een md5 of sha1 er omheen zetten wordt ook vaak gebruikt. Het staat gewoon op de eerste pagina van php.net

Heb je een linkje? Ik zie 't niet?

Verwijderd schreef op woensdag 23 januari 2013 @ 20:38:
Met md5 erom krijg je 23 tekens en met sha1 erom 40 tekens.

(Je bedoelt 32 i.p.v. 23 )
Met RandomSting(37); krijg je er 37... wat je is punt? En je begrijpt wel dat je met een uniqid() met vele lagere entropie dan een md5/sha1 zelfs méér kans hebt op hash id collisions?

offtopic:
Specifiek:
uniqid  : 4503599627370495 mogelijke id's (52 bits, 92 bits als je more_entropy gebruikt)
(G/U)UID: 340282366920938463463374607431768211456 (128 bits) unieke hashes/id's
MD5     : 340282366920938463463374607431768211456 (128 bits) unieke hashes/id's
SHA1    : 1461501637330902918203684832716283019655932542976 (160 bits) unieke hashes
Doordat je md5/sha1 trekt op een uniqid hou je dus maar een fractie van de mogelijkheden over. Daarbij staat letterlijk in de documentatie:
"...in fact without being passed any additional parameters the return value is little different from microtime()" - daarmee is de kans op collisions dus nog eens een factor groter (en uit je startpost concludeer ik toch écht dat je more_entropy niet (eens) gebruikt)

Verwijderd schreef op woensdag 23 januari 2013 @ 20:38:
Handig voor het geven van een unieke naam aan een upgeload plaatje. Komt op veel grote sites voor, je kan het natuurlijk zo zien aan de naam van de plaatjes.

Dat is dan ook een heel ander scenario

Verwijderd schreef op woensdag 23 januari 2013 @ 20:38:
En dan ook nog maar een voorbeeld: Bij het overzetten van 100 autogenummerde artikelen met elk 10 foto's naar een andere database gaat het mis. De 100 id's van de nieuwe artikelen bestaan al lang in de huidige database. Dus een probleem met de id's. De bijbehorende 100x10=1000 foto's van die artikelen wijzen allemaal naar de id's van die artikelen die veranderd moeten gaan worden, dus alle verwijsid's van alle 1000 foto's moeten dus ook aangepast worden. Met unieke id's had je dit probleem niet gehad.

Ook dat is een specifiek scenario (waarbij "hernummeren" soms nog steeds een betere optie is). Maar zeg eens eerlijk: hoe vaak heb je dat gebruikt/nodig gehad?

Ik snap, eerlijk gezegd, niet zo waarom je zo op je achterpoten staat terwijl je gewoon (IMHO toch nog binnen de grenzen van 't fatsoenlijke, maar kaart 't gerust aan in Feedback op moderatie binnen de Devschuur) op een aantal (potentiële) problemen wordt gewezen.

En, maar dit is mijn persoonlijke mening en verder niet héél spannend (maar toch wel een beetje als je 't mij vraagt), ik vind een url als foo.com/product/3 nog altijd mooier dan foo.com/product/77de68daecd823babbb58edb1c8e14d7106e83bb.

[ Voor 66% gewijzigd door RobIII op 23-01-2013 22:34 ]

[Verwijderd]

@RobIII: Ja okee, ik waardeer het zeker. Dat had ik ook al vaker gezegd in dit topic! Alleen de manier waarop moet wel een beetje leuk blijven.

Hoe kom je erbij dat ik een like zou hebben gedaan? Dat was helemaal niet het geval. Ik haalde alleen een string die was meegegeven in een form uit elkaar op de volgende pagina. Die string was zoals gezegd opgebouwd uit een id, maat en kleur. Maar het was zomaar een voorbeeld wat ik aanhaalde en dat zei ik er ook al bij dat ik het niet meer precies wist hoe of wat er nou aan de hand was destijds.

Maar goed, ik heb net nog een ander voorbeeld gegeven. Maar verder probeer ik het maar niet meer want ik moet blijkbaar elke letter afwegen voordat ik hem post omdat ik anders weer de wind van voren krijg.

Je linkjes had ik al bekeken trouwens.

Maar als ik zomaar elke blogger moet geloven of de makers van bijvoorbeeld een bepaald product of programmeertaal, dan ben ik geneigd niet zomaar zonder meer de mening van de blogger te geloven. Weer andere bloggers zeggen weer wat anders. Ieder heeft zijn voorkeuren voor elke verschillende situatie.

De pagina is: http://php.net/manual/en/function.uniqid.php
En dan een beetje onderaan in het commentaar/aanvullingen. Maar ook op Google kom ik het tegen.
Ik had geen punt met 32 of 40 tekens, dat was alleen maar om de post makkelijker te vinden.

Over uniqid + sha1: Okee dat ben ik met je eens, dat is duidelijk, thankt. Ik had dat een tijdje terug dan te gemakkelijk van bovenstaand voorbeeld overgenomen en gebruikt. Ik gebruik wel de true erachter trouwens.

Ja, hernummeren zou ook kunnen. Zelf heb ik de problemen echt ondervonden, anders had ik het echt niet opgeschreven. Ik heb het met verhuizen en importeren 2x gehad en nog 2x problemen met de autonummering met wat anders.

"Ik vind een url als foo.com/product/3 nog altijd mooier dan foo.com/product/77de68daecd823babbb58edb1c8e14d7106e83bb"
Ja klopt, dat vind ik ook. Maar dit is pas stap 1 he? Bedoeling is dat het zoiets wordt als foo.com/product/fiets. Dus vandaar die slug vraag waar dit topic eigenlijk over ging.

Okee, laat ik dan de vraag eens aan jullie stellen. Stel (ook al zou je het niet doen, dus stel), jullie moeten een UUID gebruiken in PHP, welk nemen jullie dan?

[ Voor 63% gewijzigd door Verwijderd op 24-01-2013 00:37 ]

[RobIII]

Verwijderd schreef op woensdag 23 januari 2013 @ 20:56:
Ja okee, maar hoe kom je erbij dat ik een like zou hebben gedaan? Dat was helemaal niet het geval.

Dat was wel precies wat je beschreef; ik kan dat gedrag niet anders verklaren.

Verwijderd schreef op woensdag 23 januari 2013 @ 20:56:
Je linkjes had ik al bekeken trouwens.

Maar, en ik bedoel dit echt niet niet denigrerend, heb je ze ook begrepen? Je weet wat de implicaties zijn van een UUID/GUID t.o.v. een "gewoon" auto-inc veld (a.k.a. identity)? Want dan begrijp ik niet waarom je er nog voor zou kiezen een UUID/GUID te gebruiken.

Verwijderd schreef op woensdag 23 januari 2013 @ 20:56:
De pagina is: http://php.net/manual/en/function.uniqid.php
En dan een beetje onderaan in het commentaar/aanvullingen.

Aaaah, de comments Ja, daar staan wat juweeltjes in soms Wat die meuk in de documentatie te zoeken heeft is me nog steeds een raadsel

Verwijderd schreef op woensdag 23 januari 2013 @ 20:56:
Ja klopt, dat vind ik ook. Maar dit is pas stap 1 dus vandaar die slug vraag waar dit topic eigenlijk over ging.

As said: veldje "slug" bij maken (of hoe je 't ook wil noemen), unique constraint + index erop en gaan. Heel veel spannender dan dat is 't niet. Je query wordt i.p.v. ...where `id` = 123... dan ...where `slug` = 'kleine-fiets'... (denk aan SQL injection e.d.! Gebruik bij voorkeur Parametrized Queries oid) en je moet een "duplicate key" exception vangen bij 't opslaan van een 'artikel' en een melding 'slug bestaat al' geven in dat geval. C'est tout (ongeveer )

[ Voor 53% gewijzigd door RobIII op 23-01-2013 21:27 ]

[Jurgle]

Maar als de (waardevolle on-topic) linkjes van Roblll bekeken zijn, ben ik eigenlijk wel benieuwd naar meer informatie waarom auto increment de rug wordt toegekeerd. "In het verleden problemen mee gehad," ok, maar wat waren die problemen dan? Waarom sta je negatief tegenover een auto increment int als id? (Zeker in een situatie als wat de bestandsnaam 'show_item.php' impliceert.)

[Gomez12]

Verwijderd schreef op woensdag 23 januari 2013 @ 20:56:
Maar als ik een of andere blogger moet geloven of de makers van een bepaald product, dan ben ik geneigd niet zomaar de mening van de blogger te geloven.

De pagina is: http://php.net/manual/en/function.uniqid.php
En dan een beetje onderaan in het commentaar/aanvullingen. Maar ook op Google kom ik het tegen.
Ik had geen punt met 32 of 40 tekens, dat was alleen maar om de post makkelijker te vinden.

Dus oftewel, je hebt mensen die de tijd nemen jouw specifieke vraag te beantwoorden vs comments op php.net (wat zo ongeveer het meest baggere stuk ooit is op een documentatie gedeelte)

Ja, hernummeren zou ook kunnen. Zelf heb ik de problemen echt ondervonden, anders had ik het echt niet opgeschreven. Ik heb het met importeren 2x gehad en nog 2x problemen met de autonummering met wat anders.

De ondervonden "problemen" zullen er vast ook wel geweest zijn, maar heb je ook enig idee waarom die er waren? Het heeft namelijk te maken met een basisbeginsel dat je je id's niet moet veranderen (of anders overal moet veranderen).

Met jouw actie heb je simpelweg de id's verandert op het moment dat je ze inleest. Op het moment dat jij het gaat inlezen in een mysql kolom van 6 chars breed dan heb je net zo hard hetzelfde probleem.

Even uit mijn hoofd had je het volgende kunnen doen :
1 : Kolom aanmaken in mysql en niet op auto-inc zetten
2 : Importeren met de oude id's
3 : Max_auto_id (of hoe die variabele ook heet) goedzetten en daarna auto-inc weer aanzetten.

Okee, laat ik dan de vraag eens aan jullie stellen. Stel (ook al zou je het niet doen, dus stel), jullie moeten een UUID gebruiken in PHP, welk nemen jullie dan?

Wedervraag : Wat vind je zelf beter, een uniq_id of simpelweg het 1e karakter van je uniq_id? Want met je sha1 doe je iets soortgelijks als simpelweg strleft(uniq_id,1).
Je verkleint de entropy behoorlijk (zie post van RobIII voor de getallen) en dus ga je ooit doublures/rare problemen krijgen.

Wil je een UUID hebben dan pak je uniq_id en daar ga je niet meer de entropy van verlagen, want dan heb je geen UUID meer. Maar een grotendeels UUID

[Verwijderd]

@Gomez12: Ja, ik heb het verder bestudeerd allemaal en het is nu allemaal duidelijk over uniqid en sha1 hoor, ik had mijn vorige berichtje nog aangepast. Ja het is logisch als je de ene op de andere loslaat dat je dan minder unieke resultaten overhoudt. Dus antwoord op je wedervraag: gewoon alleen uniqid() of nog beter alleen uniqid('', true). Okee dat weet ik dan ook weer over de comments op php.net.

Nee, ik zou de id's niet eens kunnen hebben inlezen want die bestonden al in de database. Kijk, als er al records met id's 1 t/ 2000 in de databse zitten, en ik kom dan later aan met een zwik extra records (zeg van een overgenomen bedrijf) met id's 50 t/m 150 dan krijg ik al de melding dat het er niet in kan ook al zet ik de kolom niet op auto-inc. Wat logisch is want ze zijn immers niet uniek als er meer van hetzelfde geprobeerd wordt in te laden.

@ Jurgle: Die voorbeelden had ik al gegeven. Dus zoiets als ik hierboven en die van een bladzijde terug, maar dat is een erg onduidelijk voorbeeld omdat ik zelf ook niet meer precies weet hoe het zat.

@ RobIII: Klopt dat had zomaar gekund maar dat was het niet. Als het goed is ga ik het probleem weer tegenkomen deze week dus dan zal ik me vanzelf wel melden ermee.

Yes, ik heb het begrepen. Kijk, ik heb geen ingewikkelde databases en de sites worden maar onderhouden door 1 persoon. Misschien is er dan naast gewenning en een aantal slechte ervaringen vroeger wel een beetje een psychologisch iets. Gewoon een database die nergens van afhankelijk is, van geen 1 autonummertje. Die helemaal compleet is waar je hem ook aan toevoegt of waartussen je hem prutst.



Ha, dat was eigenlijk precies zoals ik het wilde gaan doen. Alleen met Parametrizied Queries nog geen ervaring maar ik zal ernaar kijken.

Thanks all.

[Guillome]

Verwijderd schreef op woensdag 23 januari 2013 @ 20:38:
[...]


Inderdaad. Ik snap al die hysterie daarover hier nu niet zo, en de bijbehorende aanvallen/verwijten/vooroordelen aan mijn adres...

Ik haak af. Koppig en snauwend terwijl je antwoord krijgt op je hulp vragen. Ondankbaar.
Als jij denkt het beter te weten (uit voorbeeld uit 1999 notabene!) dan heb je ons toch niet nodig?

[kwaakvaak_v2]

Guillome schreef op donderdag 24 januari 2013 @ 09:30:
[...]


Ik haak af. Koppig en snauwend terwijl je antwoord krijgt op je hulp vragen. Ondankbaar.
Als jij denkt het beter te weten (uit voorbeeld uit 1999 notabene!) dan heb je ons toch niet nodig?

Niet om TS te verdedigen ofzo, maar de koppigheid van de gemiddelde tweaker is soms ook tenenkrommend. En dit topic is er een goed voorbeeld van. In het 'boekje' staat dat je autoincrements moet gebruiken! En zodra iemand daar soort van bewust van afwijkt, krijg je een tirade over je heen omdat het niet zo hoort want het 'boekje' en een paar blogposts beweren dat het problemen kan geven. Terwijl er wel degelijk situaties bestaan dat het juist makkelijker is om hier vanaf te wijken. Durf te wedden dat er ook blogposts te vinden zijn waarin autoincrements worden afgeraden en je beter iets anders kunt gebruiken.

Durf ook eens buiten je comfortabele doosje te denken mensen

[ Voor 12% gewijzigd door kwaakvaak_v2 op 24-01-2013 12:33 ]

[Guillome]

We hebben het duidelijk over zijn argumenten, case en vragen. Er wordt aangegeven dat het in een aantal gevallen een prima methode is, maar niet voor zijn geval.

Dus mijns inziens heb jij het mis.

[TheNephilim]

Mijn n00b visie nog even; gewoon een auto_increment gebruiken in MySQL. Krijg je makkelijk terug met LAST_INSERT_ID() in SQL of $mysqli->insert_id; in PHP.

Aan de kant van de clients zijn links als /pagina-titel-slug of /123/pagina-titel-slug of /nieuws/123/artikel-titel-slug altijd netjes. Een beetje afhankelijk van de situatie natuurlijk.

[Gomez12]

kwaakvaak_v2 schreef op donderdag 24 januari 2013 @ 12:30:
[...]
Niet om TS te verdedigen ofzo, maar de koppigheid van de gemiddelde tweaker is soms ook tenenkrommend. En dit topic deze post is er een goed voorbeeld van.

Lees aub eerst eens het topic, het gaat niet over "volgens het boekje", het gaat niet over het algemeen afraden van UUID's.

Het gaat hier specifiek over een half vernaggelde vorm van UUID die TS gebruikte en dan binnen de case door de TS gegeven.

[Verwijderd]

Onder wat voorbeelden op internet kwam ik o.a. deze tegen: http://stackoverflow.com/...-for-random-unique-tokens

Als je naar het als antwoord gemarkeerde stukje kijkt, zie je dat hij het volgende zegt: "sha1() does not make it more random, in fact it introduces the possibility of a natural collision. Although this is a possibility it will not happen in our life times so its safe."

Ook al gebruik ik de sha1 inmiddels niet meer, ik ben toch wel benieuwd na hoeveel gegenereerde id's je die collision dan wel hebt. Hij doet net of dat na tig miljard id's of duizenden jaren een keer het geval gaat zijn, maar ik was in de veronderstelling dat de collision dan net zo goed morgen als over miljoen jaar zou kunnen optreden. Dus is die uitspraak van hem 'dit zal niet gebeuren in onze life times' juist?

[Caelorum]

Het kan net zo goed na een seconde zijn lijkt mij.

[RobIII]

Verwijderd schreef op maandag 28 januari 2013 @ 23:09:
Ook al gebruik ik de sha1 inmiddels niet meer, ik ben toch wel benieuwd na hoeveel gegenereerde id's je die collision dan wel hebt. Hij doet net of dat na tig miljard id's of duizenden jaren een keer het geval gaat zijn, maar ik was in de veronderstelling dat de collision dan net zo goed morgen als over miljoen jaar zou kunnen optreden. Dus is die uitspraak van hem 'dit zal niet gebeuren in onze life times' juist?

Een SHA1 an-sich, when used as intended, zal niet snel een collision geven ("not in our lifetime"). Echter je voorziet de SHA1 van uniqid waar (o.a.) tijdsinformatie in verwerkt zit. Als je dus op meerdere systemen ID's aan 't genereren bent en er worden er twee op dezelfde tijd gegenereerd dan krijg je twee dezelfde "uniqid's" en dus twee dezelfde hashes. Even heel simpel, de resolutie is in werkelijkheid wat hoger, maar als je uitgaat van secondes als resolutie: Als je op, zeg, 28 januari 2013 op 23:28:14 op systeem X een id genereert en een ander systeem Y doet dat ook op 'tzelfde tijdstip dan heb je dus al een collision want: beide inputs voor de hash zijn 'tzelfde en dus de outputs ook.

En dan: uniqid kan maar X unieke waardes voor je genereren (zie een eerdere post van me); daar nog een SHA1 (of een andere hash die >52/92 bits output) overheen trekken is nutteloos. Simpeler gezien: stel je hebt een functie "myuniqid" die een "unieke waarde" van 0-9 output. Dan zijn er max. 10 mogelijke uitkomsten van die functie; elk van die 10 uitkomsten heeft (at best!) een unieke hash. De overige paar ziljard hashes zullen nooit uit je hashfunctie komen rollen simpelweg omdat je maar 10 verschillende inputs voor die functie hebt.

Wanneer een collision in de praktijk zich zal voordoen is nogal afhankelijk van de use-case. Doe je bijvoorbeeld grote batches van records verwerken in "tight loops" dan is er (mogelijk op een enkel systeem al, misschien wel al binnen dezelfde thread (ik ken de (exacte) implementatie van uniqid niet) en anders bij mulithreading eerder) kans op een collision binnen dezelfde "microseconde". Schaal je horizontaal naar een dikke serverfarm waar elk van die servers ID's staan te genereren aan de lopende band dan loopt de kans op collisions ook snel op. En genereer je, bij wijze van, maar 5 id's per dag dan is de kans op een collision (erg) klein. En de kans bij "merges" van databases is natuurlijk ook groter naarmate het aantal records groeit (ofwel: kleiner naarmate 't aantal records laag blijft).

En, ik ben verder zeker geen expert ofzo, er komt vast ook nog wel ergens de Birthday paradox om de hoek kijken (correct me if I'm wrong )

Het "ergste" wat je hiermee eigenlijk doet/deed (en waarom ik er over begon, collisions zijn bijzaak in deze en nogal afhankelijk, zoals gezegd, van de use-case) is dat je een hoop nutteloze bytes in je "id" verwerkt (zie m'n 0-9 input == max 10 unieke hashes output verhaaltje; waarom dan toch 128 of 160 bits verkwisten als je output in 4 bits past, ofwel 52/92 bits voor uniqid) terwijl je dan net zo goed gewoon uniqid had kunnen gebruiken. En die is dan ook nog "mooi oplopend" waardoor bijv. clustered indexes e.d. veel beter onderhouden kunnen worden (lees: inserts beter zullen performen etc).

[ Voor 34% gewijzigd door RobIII op 29-01-2013 00:11 ]

[Rob]

Verwijderd schreef op maandag 28 januari 2013 @ 23:09:
Onder wat voorbeelden op internet kwam ik o.a. deze tegen: http://stackoverflow.com/...-for-random-unique-tokens

Als je naar het als antwoord gemarkeerde stukje kijkt, zie je dat hij het volgende zegt: "sha1() does not make it more random, in fact it introduces the possibility of a natural collision. Although this is a possibility it will not happen in our life times so its safe."

Ook dat is een comment die je aanhaalt. Maar ik blijf van mening: als de kans er is dat er een collision kan ontstaan, dan moet je het niet gebruiken, ook al is het in 100miljoenmiljard jaar

Uiteindelijk hebben we dus 3 redenen om een auto-increment te gebruiken:
- Geen collisions
- De database maakt het ID aan, niet de app
- Een ID neemt veel minder geheugen in dan een hash

[Gomez12]

Rob schreef op dinsdag 29 januari 2013 @ 10:00:
[...]
Ook dat is een comment die je aanhaalt. Maar ik blijf van mening: als de kans er is dat er een collision kan ontstaan, dan moet je het niet gebruiken, ook al is het in 100miljoenmiljard jaar

Dus jij gebruikt helemaal geen id's in je apps? Alles heeft een kans op collisions. Voor een numeriek veld ligt het collision punt simpelweg op de max-waarde...

Het enige wat auto-inc velden als voordeel hebben is dat je collisions kan zien aankomen. Maar als je in geen 100miljoenmiljard jaar collisions wilt hebben moet je simpelweg het niet op de computer doen...

[Rob]

Gomez12 schreef op dinsdag 29 januari 2013 @ 10:12:
[...]

Dus jij gebruikt helemaal geen id's in je apps? Alles heeft een kans op collisions. Voor een numeriek veld ligt het collision punt simpelweg op de max-waarde...

Het enige wat auto-inc velden als voordeel hebben is dat je collisions kan zien aankomen. Maar als je in geen 100miljoenmiljard jaar collisions wilt hebben moet je simpelweg het niet op de computer doen...

Er zal geen collision ontstaan omdat de database het ID genereert, ontstaat er iets dat niet unieks dan is dat geen probleem van de app, maar is er iets goeds mis in de database.

[Verwijderd]

Okee, maar er zijn ook situaties dat ik zo'n id in 2 tabellen moet inserten. Nu is dat makkelijk, want ik genereer eerst een id en dat insert ik later in 2 tabellen. Maar als ik eerst een insert in de ene tabel moet doen, dan moet ik hem eerst weer ophalen voordat ik hem in de volgende tabel kan inserten. In de tussentijd kan dan iemand toch een ander product hebben upgeload en is het laatste id toch niet meer het goede?

[Chip.]

Ik zou mij eigenlijk afvragen of je hier nog uberhaupt iets mee zou moeten doen. Vrijwel alle zoekmachines hebben al technieken geïmplementeerd die die problemen met die URL's afvingen. Ik zou zelf dus gewoon de moeite besparen en het de volgende keer gewoon meteen goed te doen.

[Verwijderd]

@ Wouser: Zoals ik het begrijp is er niet eens een verschil met meteen goed doen of achteraf inbouwen. Er blijft toch een extra veld nodig naast het bestaande id om de SEO vriendelijke naam in te zetten. Dus dat kan ook makkelijk achteraf gebeuren lijkt me.

domein.nl/fietsen/mountainbikes/giant/trapson

ziet er toch mooier uit dan

domein.nl/show.php?cat=fietsen&subcat=mountainbikes&merk=giant&product=trapson

En het lijkt me dat je met bovenstaande 2 URL's beter gevonden wordt dan met

domein.nl/show.php?cat=3&subcat=2&merk=12&product=135

waar geen enkel woord dat op het product van toepassing is in staat, toch?

[ Voor 5% gewijzigd door Verwijderd op 11-02-2013 03:07 ]

[Guillome]

Verwijderd schreef op maandag 11 februari 2013 @ 02:03:
Okee, maar er zijn ook situaties dat ik zo'n id in 2 tabellen moet inserten. Nu is dat makkelijk, want ik genereer eerst een id en dat insert ik later in 2 tabellen. Maar als ik eerst een insert in de ene tabel moet doen, dan moet ik hem eerst weer ophalen voordat ik hem in de volgende tabel kan inserten. In de tussentijd kan dan iemand toch een ander product hebben upgeload en is het laatste id toch niet meer het goede?

Basiskennis. select @@insert id oid. Of mysql_insert_id() of of of... zoek daar maar eens op

[Verwijderd]

Ik heb inmiddels al mijn UUID's vervangen door autonummering. En waar ik het laatst gegenereerde id ook nog in een andere tabel moest inserten heb ik LAST_INSERT_ID() gebruikt. Eigenlijk geen problemen tegengekomen. Dank allen.

[Guillome]

Top!

[Verwijderd]