HEX-kod som unique ID i MySql

Hej!

Har funderat lite på vad som är smidigast att använda som unique id i mysql-databaser? Tycker det är lite kasst i MySql där man i princip by default kör med increment int. Har nu funderat på att sköta indexeringen mha en 20 tecken lång hex-sträng, som jag sett att man gör i andra databaser.

Vad borde vara smidigast, rent indexeringsmässigt, att använda för datatyp för detta ändamål, är det VARCHAR (som jag har för mig är någon fuskblandning och långsam), eller finns det någon HEX-datatyp som jag totalt har missat?

Jag tänkte mest använda hex-representation för att det blir färre tecken än binärt eller decimalt. 20 tecken är kanske lite att ta i, för det blir väl 16^20 stycken id:s vilket man inte lär komma i närheten av...

Jag kan ju naturligtvis använda en hash också. Det kan man väl dessutom ställa in så att databasmotorn "by default" lägger använder en 32-bitars hash som nyckel?

Hur menar du förresten att man skall kombinera dem? Ha en hash och en auto-inc som tillsammans bildar en nyckel?

Det är sant, mycket blir det.

Känner du till om det finns någon inbyggd funktion i MySql som skapar en indexerbar hexsträng?

Då är det alltså idé att använda bigint. Indexeringsmässigt så borde detväl vara smidigt att ha integers istället för VARCHAR. Dock så lagras väl även CHAR som ett numeriskt värde, så ur prestandasynpunkt kanske det borde vara hugget som stucket? Om man dessutom kör unsigned så borde man få ytterligare en bit att lagra info på. Fast BIGINT kanske per definition är unsigned?

Absolut, skall kolla vidare på denna!! Jag skall nog sluta försöka lösa problem mitt i natten, och leta själv istället. Nu kände jag mig bara extremt lat, förlåt.

Jo, det vet jag. Min tanke var att från början köra en indexering på VARCHAR, vilket jag misstänker blir förfärligt ur prestandasynpunkt om man jämför med BIGINT eller CHAR. Jag tror jag blandade ihop hashsummor och id...

Förresten, om jag anger en datatyp som binär, påverkar detta prestandan i indexeringen? T.ex. att overheaddata försvinner osv? Sen så pratade någon om att kombinera id med hash, vad tjänar man på det? Har inte sysslat med hashning tidigare mer än att spara lösenord...

Haha, när du skriver det sådär så är det ju onekligen så att det verkar aningen för mycket. Fyra miljarder is the shit.

EDIT: Det är med unsigned du räknar då, antar jag? Annars så går det väl från -2^31 till +2^31?

Haha, du har alldeles rätt!

Nej, det har inget med att det ser "tuffare" ut. Min far jobbar nämligen med databaser i ganska stor skala (affärssystem och transaktionssystem) och vad jag har sett så kör de med "unique identifier" istället för auto-inc int. Antar att det finns en anledning till detta. Sedan kör de ju inte mysql i produktionsmiljöerna, tror det är oracle som är den stora hos dem.

Jag är nog relativt övertygad nu i alla fall. Jag kör på int som primary key. Skulle det otroliga hända, att jag får problem med för lite rader så är det ett senare problem. Mycket senare problem...

Svaret är helt enkelt att en UUID/GUID genereras för att vara unik "i tid och rum", det vill säga att det är i princip omöjligt att generera den igen (vilket inte är fallet med INT). Detta hade fördelar när man arbetar med många och stora databaser, då man ofta har många olika tabeller vars nycklar helt enkelt måste vara unika. I fallet med integer blir ju dessa inte unika då du i så fall börjar på 1 i varje ny tabell.

INSERT INTO [Users] ([Id], [Username]) VALUES ('000000-0000-0000-000000', 'Username');
INSERT INTO [Posts] ([Id], [User], [Text]) VALUES ('000000-0000-0000-000000', '000000-0000-0000-000000', 'Kalle Erik Petter');

DECLARE @UserId INTEGER;
INSERT INTO [Users] ([Username]) VALUES ('Username');

SET @UserId = SCOPE_IDENTITY();

INSERT INTO [Posts] ([User], [Text]) VALUES (@UserId, 'Kalle Erik Petter');

Precis, där ligger förmodligen också en del. Som jag har förstått det så genereras UUID/GUID utifrån unix-timestamp, randomnummer (frö) och datorns id (typ ethernet-mac). Även om sannolikheten finns att denna 128-bitars nyckel inte skulle vara unik (även i en enorm databas), är den nog i likhet med att hitta ett riskorn i vårt solsystem...

Kan även tillägga att jag nu på nytt bestämt mig för att använda UUID istället för INT som primärnycklar.

Av den enkla anledningen att med UUID så blir nyckeln unik i hela databasen istället för bara i tabellen.

När det gäller snabbhet så är kanske INT snabbare (borde ju vara), men jag tror inte det handlar om direkt långa fördröjningar. Vore ju trevligt att se siffror på detta. Som det är nu lagrar jag nyckeln i en CHAR(36), vilket egentligen är INT med en annan formatering. Vet dock inte hur databasen i sig lagrar det, det skiljer nog mellan olika databasmotorer...

Jag vet inte om det är så mycket mer enkelt att använda auto-inc INT. Som det är nu så har jag möjlighet att skapa UUID via programkoden (Java) alternativt direkt i databasanropet (mha funktionen UUID()). Plus att vid många tabeller behöver man inte oroa sig för dryga databasfel som uppstå pga att man förväxlat två tabellers id, vilket i fallet med INT resulterar i ett felaktigt svar (eftersom id:t med största sannolikhet existerar i båda tabeller)

Funderar dock på vad som är smidigast att spara UUID:er som i databasen? Jag använder, som jag tidigare nämnt, CHAR(36) för att det är en "primitiv datatyp" (iaf inom många programspråk) så det borde inte vara så mycket over-head. Nån som har koll på detta?

Det blir fler jämförelser, det är sant.

Håller med om att argumentet om "dryga databasfel" var lite missvisande. Det jag menar var ifall du har flera tabeller ihopkopplade och varje tabell har ett enskilt nummer kopplat till sig (som återfinns i andra tabeller) så kan det enklare uppstå "felkopplingar" vid t.ex. sammanslagning av tabeller. Då uppkommer problemet att du får samma ID på två ställen som refererar till olika poster. Detta blir inte fallet med UUID, då den är universiellt unik.

Detta är förmodligen även en av anledningarna till att auto-inc INT inte används ute i de större databaserna.

Det är möjligt att det används i stora databassystem. De enda större databassystem jag har någon insyn i är de min pappa jobbar med (MIO, LKAB, Getinge, etc) och där används GUID istället för INT, och som jag förstod det så är det där mycket viktigt att varje rad i varje tabell är given ett globalt unikt värde, eftersom det oftast är flera databaser inblandade som sköter samma typ av transaktioner.

Ta t.ex. ett kassasytem för ett stort företag. För att klara den enorma mängden transaktioner som genomförs per dag måste det spridas på flera databaser. Kan tänka mig kanske 1 per varuhus. När dessa sedan skickas till "huvudkontorets" databas för att sammanställa dagens försäljning, så hade det blivit extremt knepigt ifall det hade kommit 2 miljoner rader med samma tabell-id fast med olika innehåll. Detta problemet löses med UUID eftersom det genereras delvis mha datorns MAC-adress. Resultatet blir att alla 2 miljoner raderna är unika, och kan migreras utan vidare behandling. - Man sparar tid här, men förlorar tid vid insättningen i tabellen.

Notera att jag inte säger att auto-inc int är dåligt på något sätt. Det, liksom UUID har sina fördelar och nackdelar. I ett mindre projekt (som t.ex. mitt i detta fallet) där man bara har en databas inblandad så finns det kanske ingen praktisk anledning att använda något annat än auto-inc int. Samtidigt så blir det inga större förluster att använda UUID när det handlar om så små volymer.

Anledningen till att jag väljer UUID är för att jag lätt vill kunna delegera arbetet på flera (och olika) databaser, t.ex. X10, MS SQL, postgreSQL, MySql, DB2, m.fl. Det är alltså i rent "utbildningssyfte", och inte en ren prestandaåtgärd.

Tackar för det. Skall kolla lite extra på det med binary, det verkar onekligen värt att läsa på mer om!

Inom vanlig programmering kan du ju casta mellan INT och CHAR utan vidare. Jag antog att man "sparade" de på samma sätt här.

Absolut har man det. Se min tidigare post, jag menade vid migrering av databaser.

Det är förmodligen av denna anledning som de kör uuid och inte auto-inc int. Men båda har, som sagt, sina fördelar. Allt beror ju på användningsområdet. UUID har väl sina starka fördelar vid många förfrågningar samtidigt, då ID:t kan skapas direkt i klienten, som nämndes tidigare.

Får kanske bestämma mig för att byta till auto-inc int Vi får se hur det blir. Såg att det fanns mycket att läsa om detta på nätet. Tydligen är det inte första gången frågan har dykt upp.