Först lediga Id i mySQL
 

En tabell med ett Id enligt

CREATE TABLE MinTabell (
Id bigint unsigned NOT NULL AUTO_INCREMENT,
...
...


Efterhand har vissa poster raderats och det blir "hål" i följden av Id:en
Låt säga att Id ser ut så sorterade asc.
1
2
3
4
5
6
11
12
13
14
...
...
...

Finns det någon sql-sats som leter upp första lediga Id, i detta fall Id = 7 ?

Dessutom vill jag har svar på hur stort "hålet" är, dvs hur många oanvända Id det finns
iföljd från och med 7. I detta fall 4 st ( 7,8,9,10 )?


Två tillfällen som jag vill använda detta.
a. När en ny post ska läggas till så ska första lediga Id användas.
b. "Packa" ihop posterna så att alla "hål" försvinner.


på Serverversion: 5.0.51b så letar denna SQL-sats upp första lediga Id
select Id+1 as lastId from MinTabell where (select count(*) from MinTabell where Id = lastId) = 0 limit 1

På
Server version: 5.0.75
Server version: 5.1.42
Server version: 5.1.50
får jag
ERROR 1054 (42S22): Unknown column 'lastId' in 'where clause'


Varför göra detta nu då? Jo det kan man ju fråga sig.
Varför ska osten skäras på ett visst sätt? Varför ska ljusen på bordet så i exakta rader? osv
Fobier kanske ...

Har det någon betydelse ur effektivitetssynpunkt?
Kan tillägga att en tabell för närvarande innehåller drygt 68 milj poster.

Återanvänd inte id:n. Vad händer om det finns kvar referenser i andra tabeller till den gamla raden?

Unsigned bigint har maxvärde 18446744073709551615 så du har mao ett tag kvar innan du behöver oroa dig för att få slut på dem ;)

Om du nödvändigtvis någon gång vill bli av med "hålen" så föreslår jag en export av datan + en import utan att importera id-kolumnen, med en återställd auto_increment-räknare. På så sätt får alla rader nya id:n från 1 och uppåt. Men att göra det är nog snarare lätt neurotiskt än effektivitetsbefrämjande :)

Nej, det har ingen som helst betydelse ur effektivitetssynpunkt. Enda gången det skulle kunna påverka effektiviteten är om datatypen tar slut så du måste välja en större datatyp, till exempel använda BIGINT istället för INT. Då krävs mer RAM för att hålla indexet i minnet och det tar större plats på disk (båda två saker som kan påverka prestandan).

Men så länge du bara har hål och långt kvar till "taket" verkar det bara trassligt att "täppa igen" hålen. Som MMC säger ställer det till med problem om du har andra tabeller som relaterar till den du jobbar med nu. Tänk om du har gamla data kvar som då plötsligt ofrivilligt kopplas till den här tabellen? Eller om du har externa tjänster som också använder id-numret. Om du till exempel tagit bort en webbsida så kanske det är bättre att besökaren får veta det än att de kommer till en helt ny sida.

Just i det specifika fallet så finns inga referenser från andra tabeller till Id:et och kommer aldirg att finnas heller.

Men dina ord är nog kloka ändå. Jag får försöka komma över mina "städfobier" :-)

Generellt bör man vara försiktig med att använda autoincrement om det finns en naturlig primärnycken man kan använda i stället. Det är viktigt att man tänker igenom hur man definierar primärnyckel i varje tabell.

Jag skulle aldrig ge mig in på att "återanvända" första lediga nyckel just i en autoincrement PK. när man använder naturliga primärnycklar kan man göra det får då finns värdet definierat utanför systemet.

Syftet med autoincrement är att kunna använda en PK där inga naturliga nycklar skulle passa, exempelvis för ordernummer, fakturanummer m.m.

Där håller jag inte riktigt med.
Jag tycker det är bra att ha en autoincrement primärnyckel så ofta som möjligt. Jag tycker det är en bra struktur när man alltid kan referera till en rad med tabell.id. Om man ska naturliga primärnycklar så blir det oftast strängar och då blir indexen gigantiska(och därmed långsamma) i många fall när man har stora tabeller.

Ordernummer och fakturanummer tycker jag är bra exempel på tillfällen då man inte ska använda autoincrement utan här borde varje ID slumpas fram av säkerhetsskäl.

Det är väl ett bokföringsbrott att slumpa fram fakturanummer?

I övrigt håller jag med dig om att tekniska heltalsnycklar är bra för att få ner indexstorleken, men de är trots allt inte alltid att föredra. Det beror ju mycket på tabellen och så också. För små tabeller finns det ju liten eller ingen anledning att använda annat än naturliga primärnycklar.

En stor del av syftet/fördelen med att använda en relationsdatabas är att man kan använda s.k. uppslagstabeller av olika nyckelvärden. För att ta ett enkelt exempel; LAndskoder som SE, DE, US, FI mfl så lägger man dessa koder som primärnyckel i en tabell.

Då kan man använda denna nyckel som Främmande nyckel i andra tabeller och därmed garantera att inga ogiltiga värden lagras i de tabeller som använder dessa främmande nycklar. Du får även en inbyggd kontroll mot dubbletter i samma kolumn. Använder man autoincrement så måste man ändå lägga på ett extra unikt index på motsvarande kod-kolumnen och då har man inte vunnit något utan försämrat prestanda i databasen.

Fördelen med att använda just externt definierade nycklar är då att de erfarba användarna kan skriva in värdet direkt i inmatningsfältet och de kan då snabba upp registreringen av olika uppgifter.

Detta är ett mycket viktigt användningsområde för naturliga primärnycklar. Det är rekommenderat att man ska försöka använda dessa naturliga prmärnycklar så mycket som möjligt.

Det ger bland annat även fördelar om man ska integrera två olika system, om de använt samma naturliga externa källa för sina nycklar, det blir hiskeligt mycket enklare att göra integrationen då.

Fler och fler system bygger på principen att de ska vara små och specialicerade på färre ansvarsområden, så integrationsproblematiken blir bara mer och mer vanlig.

Ja, i exemplet med landskoder är det ju såklart en bra idé att använda landskoden som primärnyckeln.
Men jag har sett system där man t.ex. använder person-/organisationsnummer som primärnycken och sparar dessa med strecket som en stäng, dvs 000000-0000. Det ger väldigt dåliga index tycker jag även om det är ett "bra" naturligt index.

Är det verkligen så?
Jag vill inte skicka ut fakturor med ett autoincrementnummer som fakturanummer. Då kan ju alla se exakt hur många fakturor man skickar ut under en viss tidsperiod och det ser jag som en företagshemlighet...
Men det kanske bara gäller i bokföringen så man kan skriva ett annat referensnummer på fakturan man skickar ut?

http://www.wn.se/showthread.php?p=20341439
http://www.skatteverket.se/rattsinfo...800028340.html

Det är helt ok att använda datum + inkrement för det datumet. Två fakturor den 1:a december 2010 kan ha numren 101201-01 och 101201-02 och två fakturor den 2:a december 2010 får numren 101202-01 och 101202-02. Det löser väl ditt problem åtminstone delvis?

EDIT: Skatteverket må ha tolkat om sina regler men jag kör på på det systemet och varken SKV (2008) eller redovisningskonsult har haft åsikter.

Jag ser det som en tämligen värdelös företagshemlighet :) Hur som helst så går det bra att använda andra system än 1-2-3-4 osv. så länge det finns en löpande korrekt serie utan avbrott. Se lagtexten.

Okej, tack så mycket för informationen. Jag hade ingen aning om det...

Ja, det löser absolut problemet, tack!

Men det går ju inte garantera fullständigheten i bokföringsposterna då eftersom det går att plocka bort den sista fakturan på varje dag utan att serien bryts. Någon som vet om det är okej?

Jag vill helt enkelt inte skylta med exakt hur många fakturor jag har skickat ut sedan företaget bildades. Det är väl kanske inget värde i de siffrorna men det är inte något som jag vill de ut hur som helst.

Kan du exempel på några bra serier som inte avslöjar antalet fakturor som skickas ut. Man ska inte kunna jämföra en faktura med en annan faktura en månad tidigare och se hur många fakturor det har gått ut emellan de två.

Ursäkta att det blev lite off topic nu...

Om du inte vill visa hur många fakturor du skickat kan du väl börja nummerserien på nåt godtyckligt nummer, t.ex. 1234.
Första fakturan 1234, andra fakturan 1235, tionde fakturan 1244 osv.

Det hjälper mig ju inte alls eftersom jag inte vill att man ska kunna se alls hur många fakturor jag har skickat ut genom att kolla på faktura numret om man jämför två olika fakturor.

Jag började på fakturanummer 1 och nästa fick heta 2 o s v, det har aldrig varit någon som brytt sig om det på 10 år senast var det.

I andra företag har jag använt konstant längd på fakturanummr och lagt en 2-siffrig kod si början som talar om att det är en faktura, order, levernatörsfaktura eller vad det nu var. Exempel: 370001, 370002, ...

Det är vanligt att man använder årtalet i början exempelvis; 2009001, 2009002... och nästa år börjar på 2010001, 2010002, ...

Har även sett varianter med hela datum och löpnr inom datumet, exempelvis 2009030501, 2009040701, ... (dessa följer inte principn med obruten serie onom året men varken revisor eller skatteverk har anmäkt på detta).

Det finns många företag som tar lång tid på sig att skriva sna fakturor då man omedelbart vid order börjar upprätta fakturan och därmed åsätter den ett faktranummer men att det kan hinna upprätas många fler fakturor med senare nummer innan den första fakturan skickas iväg, dett a är inte heller ett problem.


Så jag skulle vilja påstå att "obruten serie inom året" inte är ett 100-procentigt krav utan något skatteverket önskar, men inte stenhårt kräver....