Lite tabelloptimering

Hej,

Har just fått reda på en suverän grej med mySQL, nämligen att skapa index mellan två fält i en tabell.

Men jag har dock lite frågor:

1. Som jag förstått det skall man använda detta för att skapa "nästan som sammansatta nycklar". Dvs, om jag inte har någon primärnyckel utan bara främmande nycklar så kombinerar man detta till ett index för att få det snabbare. Stämmer detta?

2. En primärnyckel är ju alltid UNIK, motsvarar ett index av flera fält tillsammans samma princip, dvs en primärnyckel som sträcker sig över flera fält (förutsatt att jag var smart nog att sätta index på sådana fält som ger en unik kombination)?

3. Är det dumt att _inte_ använda sig av en räknare som man sätter till primärnyckel? Så som jag resonerat så är det om jag inte kommer att arbeta mot primärnyckeln så tar den bara upp utrymme i databasen och gör inte mitt arbete lättare. Är det fel tänkt?

4. Finns fler smarta sätt att optimera i tabellerna? Mina sql frågor kan säkerts optimeras något, men vad kan man göra för själva strukturen?

Tacksam för beskrivande svar, ej händvisningar till manualer så. Om det finns trådar här som tar upp detta så hänvisa gärna, jag sökte men fann inte det jag ville veta.

// Nippe

1. Jag ser ingen fördel med att skapa ett sammansatt index för dessa kolumner. Definera dom som primärnyckel istället.

2. Nej. Primärnyckel är ett logiskt begrepp, index är en implementaionsteknik. (Unika index behövs inte, använd unique constraint i stället.)

3. Nej, se 1.

4. "Premature optimization is the root of all evil"
   Se till funktionella först.

Tack för bra svar, men

1. Om jag definierar dem som primärnycklar, kan jag definera flera fält som primärnycklar?

2. Vad är skillnaden mellan Unika index och unique constraint?

3. Du menar att utrymmet som en "meningslös" räknare tar upp är försumbart eller? Då jag ändå inte kommer att uppdatera genom att i where-satsen kolla mot denna räknare så känns det ändå onödigt...

4. :)

// Nippe

1. Nej, man kan bara ha en primärnyckel per tabell. I det typiska fallet när man har en kopplingstabell med två kolumner som pekar ut varsion tabell så skall kombinationen av dessa vara unika så de passar utmärkt som en primary key.

2. Rent praktiskt så är det inte så stor skillnad då de flesta DBMS använder ett internt index för att verifiera unique-constraint.

En skillnad är att det går att definera en foreign key mot ett unique-constraint. En annan skillnad som kan finnas är att vissa DBMS tillåter att unique constraint kan innehålla flera null medan de inte tillåter det i ett unique index.

3. Jag kanske uttryckte mig oklart men jag menade att det inte behövs någon räknare. Möjligen att man i de sällsynta fall då man har ännu fler kolumner som utgör en kandidatnyckel kan tänka sig att använda en räknare av rent hanteringsmässiga skäl.

Det här börjar ju bli som en krånglig diskussion ;)

1. Jo, precis, det är ju så jag har det. Värden från två eller flera fält i en tabell bildar en unik nyckel. Frågan var väl egentligen om jag kan sätta två fält sammanbunda så att det blir en primary key, precis som jag nu skapar index av två eller flera fält.

2. Blev inte så mycket klokare, men det är lugnt, känns som om jag kanske inte behöver sätta mig in i det just nu.. ;)

3. Jo, men det gör jag i vissa fall. Lite case by case där känns det som!

Tack för att du tar dig tiden :)

// Nippe

Det är inget problem att ha flera kolumner i en primary key.

create table persons(pnr int primary key, 
name varchar(20), ...)

create table vehicles(regnr char(6) primary key, 
make varchar(20) ... )

create table vehicleOwners(pnr int references(persons),
regnr char(6) references vehicles,
primary key(pnr,regnr))

Jag bortser från de konstiga reglerna med index som Mysql har. Dom har verkligen lyckats med att blanda ihop den logiska och den fysiska modellen.

Strålande, då ska jag försöka med det!

Du har så rätt, jag är helt virrig i huvudet nu efter alla olika saker ;)

Tack så mycket för hjälpen!

// Nippe