IDENTITY eller GUID?

Hej, jag har börjat se att fler och fler använder GUID istället
för IDENTIY i sina PRIMARY KEY:s.

Varför?

Det jag ser är följande:

Nackdelar
GUID
Långa 36 strängar
de blir långsammare att lookup i databasen
än rena tal.
Tar upp mer plats, också när man använder dem i FOREIGN KEY.

IDENTITY
"bigint" tar slut nångång vid 1000 miljarder.
därefter får man byta databas.

Fördelar:

GUID:
Kan knappast ta slut på nummer.
Lättare att flytta databaser i SQL Server 2005 där databasen är precis som en vanlig databasfil .mdf. Har man IDENTITY måste allting "räknas upp" om man har data i databasen

IDENTITY
kortare tal.
går snabbare att lookup
lättare att hantera när man använder FOREIGN KEY.

ja det var lite snabbt,. jag vill ha en grundlig diskussion om detta fenomen :)

Jag vill lägga till att använder man GUID behöver man inte använda SCOPE_IDENTITY() (om man behöver ID:et i relaterade tabeller) eftersom GUID är unika kan man skapa GUID:en på klientsidan och sen bara peta in som PRIMARY KEY vid INSERT:en .. det är ju nåt att tänka på ... Men men, har ni några egna funderaringar?, så fram med dom :)

Nöff skrev:

Jag vill lägga till att använder man GUID behöver man inte använda SCOPE_IDENTITY() (om man behöver ID:et i relaterade tabeller) eftersom GUID är unika kan man skapa GUID:en på klientsidan och sen bara peta in som PRIMARY KEY vid INSERT:en .. det är ju nåt att tänka på ... Men men, har ni några egna funderaringar?, så fram med dom :)

Vad är vitsen med det? :o

GUID fick jag höra att det ska vara en nödvändighet vid replikation, men varför det skulle vara så och om det faktiskt _är_ så vet jag inte.
Databasnamn+tabellnamn+identity/pk borde räcka alldeles utmärkt för att identifiera en unik rad i en tabell i en databas.

Det är väl säkert något fundamentalt man har missat nu igen :OO

Vad är vitsen med det?

Så man slipper göra en roundtrip till servern om man ska lägga in först 1 rad i parent tabellen och lite rader i child tabellen baserat på parenttabellens ID.

IDENTITY:

DECLARE @huvudtabellID int
DECLARE @huvudinfo varchar(255)
DECLARE @chilcinfo varchar(255)

SET @huvudinfo='test'
SET @childinfo='test'

INSERT INTO huvudtabell (info) VALUES (@huvudinfo)
SET @huvudtabellID=SCOPE_IDENTITY()
INSERT INTO childtabell (huvudtabellID,info) VALUES (@huvudtabellID,@childinfo)

Ja, oftast blir det värre än så , många returnerar ID:et ända tillbaka till sin webapplikation också genom ExecuteScalar() och liknande vilket är ännu sämre.

Men med GUID så struntar man i att låta servern generera PRIMARY KEYS utan man skapar dom själv på klientsidan. checka denna:

GUID:

DECLARE @huvudtabellID UNIQUEIDENTIFIER
DECLARE @childtabellID UNIQUEIDENTIFIER
DECLARE @huvudinfo varchar(255)
DECLARE @chilcinfo varchar(255)

SET @huvudtabellID ='1d5c0f00-155f-4a40-a926-b0ca073a266d'
SET @childtabellID ='3e794cc0-d058-45d5-81f3-e9fc64a199bc'

SET @huvudinfo='test'
SET @childinfo='test'

INSERT INTO huvudtabell (huvudtabellID,info) VALUES (@huvudinfo)
INSERT INTO childtabell (childtabellID,huvudtabellID,info) VALUES (@childtabellID,@huvudtabellID,@childinfo)

Och man kan även låta servern generera GUID:en också med NEWID() om man vill det. men men Ja, jag säger varken bu eller bä. IDENTITY känns göttast fortfarande , men säger någon att GUID är the shit så är det väl lika bra att gå över :/ Och en annan sak, när man skapar en logincontrol i VS 2005 så autogenereras en fet databas med users,members tabeller, och alla dessa använder GUID:s så jag undrar om inte GUID:s börjar bli the way to go :/

här är en artikel om GUID:s:
http://www.sqlservercentral.com/columnists/awarren/usinguniqueindentifierinsteadofidentity.asp

GUID fick jag höra att det ska vara en nödvändighet vid replikation, men varför det skulle vara så och om det faktiskt _är_ så vet jag inte.

Menar du när man ska kopiera en databas och flytta över den till en annan server?

Nöff skrev:

Menar du när man ska kopiera en databas och flytta över den till en annan server?

Uhm, nä, jag menar när den är satt att replikeras till en annan server. Förenklat kan man väl säga att det är en kopiering som sker, men det är bara halva sanningen.

Nu är jag ingen DBA och har inte gett mig in i den där härvan med replikering och allt vad det innebär, men jag är dock nyfiken. Jag gissar att det har att göra med att för att replikan ska veta att den är rätt behöver den ett globalt unikt id att jämföra tupler med, och det är väl vad ett GUID ska vara (Global Unique IDentifier?).

Uhm, nä, jag menar när den är satt att replikeras till en annan server. Förenklat kan man väl säga att det är en kopiering som sker, men det är bara halva sanningen.

Nu är jag ingen DBA och har inte gett mig in i den där härvan med replikering och allt vad det innebär, men jag är dock nyfiken. Jag gissar att det har att göra med att för att replikan ska veta att den är rätt behöver den ett globalt unikt id att jämföra tupler med, och det är väl vad ett GUID ska vara (Global Unique IDentifier?).

Jao, eller är det väl så att om man använder IDENTITY och ska försöka kopiera databasen och ladda upp sin webapplikation till webservern blir det ju genast jobbigt eftersom alla IDENTITY måste autogeneras uppåt i den takt det sätts in skit i databasen(Om man inte använder IDENTITY_INSERT, men det är ovanligt). Och en ny feature med SQL Server 2005 är att databaserna är vanliga filer kallad ".mdf" filer som kan hanteras precis som vanliga filer. Så man kan bygga en webapplikation, fylla databasen med skit och sen ladda upp webapplikationen plus SQL Server databasfilen till webservern direkt utan problem, men detta förutsätter förmodligen att man använder GUID:s antar jag, för att då behöver inte primärnyckeln autogenereras i "sin egen takt" utan man kan sätta in värdena direkt och använda dem i relationer direkt. För att kollar man på VS 2005 logincontrols autogenerede databas så är precis alla primärnycklar GUID:s, så det är nog ett stark hint att de rekommenderar att man använder GUID:s istället för IDENTITY. Tror jag iaf.