bassebhuMedlem sedan nov. 20016 480 inlägg Hej alla glada!
Just nu har jag 10 tabeller där alla har id i stigande ordning. Hur dum idé är det att i stället generera id:n med php:s uniqid() och spara 11 tecken långa strängar? Jag har ändå en datumkolumn som kan sortera i skapelseordning.
Det skulle möjliggöra följande:
Jag kan referera till längre strängar i mina querystrings i stället för det lättgissade 1, 2, 3 etc.
Jag kan (i princip) importera data hur som helst mellan olika kopior av databasen utan att stöta på konflikter med samma id:n. Jag kommer troligen inte att behöva importera grejer mellan databaserna, men om det skulle visa sig nödvändigt så behöver jag inte bygga något som kollar varenda id och relation och uppdaterar dem till nya för att det ska funka att slå samman data mellan databaser. Komplikationen är om någon i de två databaserna har sparat en post i exakt samma mikrosekund gissar jag, vilket är högst osannolikt med tanke på den lilla mängd data som kommer att hanteras. Rätta mig gärna om jag har fel.
Jag kan med hjälp av enbart ett ID få fram all resterande information jag behöver.
Vilken prestandamiss är det med denna idé?
Tack för synpunkter!
drewMedlem sedan mars 2007845 inlägg Med uniqid() måste du ändå kolla i databasen att det verkligen är ett unikt id. Att använda auto_increment är snabbare. Men hur mycket det skulle göra i prestanda beror på hur stor databas du har.
Jag skulle nog hålla mig till auto_increment.
aasahMedlem sedan mars 20034 471 inlägg
bassebhu skrev:
Just nu har jag 10 tabeller där alla har id i stigande ordning. Hur dum idé är det att i stället generera id:n med php:s uniqid() och spara 11 tecken långa strängar? Jag har ändå en datumkolumn som kan sortera i skapelseordning.
Det skulle möjliggöra följande:
Jag kan referera till längre strängar i mina querystrings i stället för det lättgissade 1, 2, 3 etc.
Och vad skulle poängen med det vara? Du kan ju aldrig hindra att någon sätter sig ner och råkar mata in ett id som faktiskt matchar något som finns. Så du måste i alla fall validera all indata ...
bassebhuMedlem sedan nov. 20016 480 inlägg Hehe, jag vet inte. Jag gillar att ID:n har samma längd och inte går att byta ut och se andra poster så lätt. Det finns säkert fler anledningar till att YouTube, Vimeo och alla de andra har såna ID:n och inte bara kronologiskt 1, 2, 3. Sen ser det proffsigare ut också.
cascaMedlem sedan feb. 20005 891 inlägg Jag vet inte riktigt vad du vill uppnå, eller hur databasens nuvarande struktur ser ut, så det är svårt att bedöma hela företaget. ;)
bassebhuMedlem sedan nov. 20016 480 inlägg hehe jag har nog skippat idén, jag tyckte bara att det verkade smutt med unika id:n för allt i hela databasen.
Och den största anledningen är som sagt om jag vill slå samman databaser är det en massa jobb att länka om alla relationer så att inget krockar. Det blir ett senare problem :)
prplxrMedlem sedan juni 2012582 inlägg YouTube kör väl ändå med base64? Inget fel med att använda det om du vill att det ska se "proffsigare" ut. Det har jag använt mig av i vissa projekt också. :-)
När jag använder det så har jag länkar som såhär: http://example.com/link/MTIwOTM-OQ==
(Jaja, jag vet, jag har bytt ut / mot -, men det var orimligt att göra annat då URLen failade med snedstreck här och var) :)
