MySQL index

man gør søgninger med = (ikke med like) mere effektive
og så bruger man mere plads, og gør inserts dyrere
(kort fortalt...)

Hvorfor bruger man mere plads?
Gør insert's dyrere?

fordi der bliver opbygget et søgetræ. Det fylder plads at opbevare, samt man ligeledes skal opdatere dette søgetræ, udover man også indsætter på normal vis, når der indsættes i databasen!

Dvs. insert tager 'længere' tid?
Det er altså godt at bruge på ofte brugte columns (SELECT)?

Ja, hvis du tit søger på fx

  ...where livret='osteskorper'

så kan man overveje at indexere livret. Men det dur ikke til

  ...where livret like '%osteskorper%'

Ahh.. men det er altså KUN møntet på
  ...where liveret != 'osteskorper' ?

Nu valgte jeg osteskorper, fordi det næppe er manges livret.
For strengt taget giver det kun en forbedring hvis det
er et mindre antal tupler man skal returnere som svar.
Groft sagt igen: med et index behøver databasen stort
set kun kigge på de relevante tupler. Er det 5 ud af
et samlet antal på 100.000 kan du selv fornemmer forskellen.

Men skriver du så != vi den i ovenstående eksempel skulle
aflevere 99.995 tupler - stort set dem allesammen - og så
er der li'som ingen besparelse, kun ekstra besvær med at
indsætte og slette fra indexet. Det kan så formentlig ikke
betale sig.

Så konklusionen er, at det kun kan betale sig at benytte index'ering når, man kan konstatere at hovedparten af ens SELECT's kun vil returnere et begrænset antal 'tupler' ?

Ja. Men det er en kunst at vælge korrekt  -  eller er det en
videnskab? Dem der kan sådan noget som det her på fingerspidserne,
bliver højtlønnede databaseadministratorer i de store virksomheder... :)

Hehe. Lyder som noget man burde øve sig i;)

Kan man forresten bruge SELECT's i default value?

"default value" ?

Nå, ja, og så er det nok ikke lige MySql, men produkter som Oracle, der
har rigtig mange parametre, der kan justeres på.

Ja i et field. En DATE ville jeg gerne kunne sætte default til nuværende dato.

Du mener vel INSERT og UPDATE ? Du kan bruge MySqls funktion: now() til
at indsætte dags dato.

Ja det er jeg klar over, men i selve default value'n når man creater en table?

Vil index'ering iøvrigt have effekt på USING() ?

Eksempel?

SELECT SUM(IF(beloeb < 0, beloeb, 0)) AS udgifter,
FROM
    balance
INNER JOIN
    medarbejder USING(medarbejder_id)

Nåh, ja, ved joins generelt vil der blive brugt indexer
hvis databaseserveren mener det kan betale sig. Så laver
du mange, bestemte, joins skal du overveje indexer på
samme måde som ved selects.

I dit eksempel vil medarbejder.medarbejder_id sikkert
være primær nøgle (og dermed indexeret), og så er
balance.medarbejder_id en fremmednøgle, og bør være
indexeret. I nyeste mysql, med den rigtige tabel-
implementation nedenunder, vi mysql vist nok forlange
at den er indexeret, når man specificerer den som
fremmednøgle.

Så fields benyttet til at samle relationer i en database bør være indexerede?

Er der egentlig forskel på PRIMARY KEY og en selv defineret key?

Ja til det første og nej til det andet - som udgangspunkt i hvert fald.

Hvad er meningen med primary key?

Det er et aikre at hver tupel (række) i tabellen med sikkerhed
har en unik identifikation, så du efterfølgende kan referere til
hver enkelt række. Der behøver ikke være en PK, men prøv
at tage sådan en tabel ind i phpmyadmin - så kan du
pludselig ikke redigere og slette enkelte rækker. fordi det
ikke længere giver mening.

Okay, men altså ikke nødvendig hvis man selv definere sine uniques.

Tak for 'sludderen' :)

Joh, nødvendig hvis du efterfølgende skal gøre noget fornuftigt
ved tabellen. Har du et andet felt, der har samme karakteristika
som en PK, så gør den da til PK.

Der kan da godt tænkes tilfælde hvor en PK kan undværes, måske.
Jeg kan nu ikke lige komme på én.... at MySql tillader, at man
ikke har en PK er en anden sag.

Samme karakteristika vil sige, at den er unique ?

Jah, er det ikke bare unique og nut noll - hehe - not null.

PK - sjofel programmering :P

Ingen svar Erik?