oskobMedlem sedan maj 20021 558 inlägg Hallå!
Jag är inte helt nere med prestanda och databaser, men i mitt huvud så känns det som att man vill hålla nere storleken på sina primary keys. Är detta något som även återspeglas i verkligheten? Tar det längre tid att läsa/skriva rader som man måste hitta med hjälp av en primary key som består av en bigint med ett skyhögt värde än en rad med int som har ett lågt värde. Och om ja, är det märkbara skillnader eller kommer det bara märkas om man gör extremt många querys?
Problemet jag står inför är att jag har en databas med extremt stora id-nummer och inte ens bigint kan längre få plats med dem. Id-numren är extremt glest fördelade och även fast det är under 400 000 rader finns det id-nummer som 4620850001001014320. Det känns väldigt ineffektivt.
Min fråga är då: Är det värt att plöja igenom tabellerna (och alla relationstabeller) och återställa dessa id-nummer så de börjar om från 1 och sen sekventiellt uppåt så de får plats i en int?
Eller: Ska jag låta de befintliga id-numren finnas och när jag skapar nya rader hitta det lägsta lediga id:t och då slippa ändra på alla id:n och dess motsvarigheter i alla relationstabeller.
Hur har du gjort för att få så höga idnummer? :)
Oavsett vilket, så länge det finns index så tror jag inte att det är mycker overhead det handlar om.
oskobMedlem sedan maj 20021 558 inlägg Okej, skönt :)
Det är en gammal funktion som ska generera nya id:n och få någon slags struktur på id-numren, tror jag det var tänkt, som verkar ha flippat ur helt :S
Tack för svaret, och eftersom det var det svaret jag ville höra väljer jag att lita fullt på dig! ;)
Indexering av ID-kolumner sker ofta i form av ett B-träd, vilket förenklat innebär att värden grupperas i kluster med närliggande värden. Att ha megastora ID-värden är i sig inget problem i sammanhanget, men om du ofta lägger in rader med slumpartade (dvs ej sekventiella) ID-värden kan kluster bli fulla, vilket kräver att indexet då och då måste byggas om, vilket under själva ombyggnaden slöar ner. Däremot ska det inte påverka matchning av id samt relationer nämnvärt.
Om du kan avslöja hur ditt index är uppbyggt så kanske vi kan kommentera närmare.
oskobMedlem sedan maj 20021 558 inlägg Eum.. ja jag vet inte exakt vad du vill veta men primary key-indexet ser ut såhär:
CREATE UNIQUE INDEX table_pkey ON table USING btree (id)
Tilläggas bör att det är postgres
Det jag vill få reda på är hur själva värdet genereras när det är dags att stoppa in ett värde.
