Toon posts:

[(My)Sql] index op foreign en primary key samen

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hoi,

Iets wat ik mij al een tijdje afvraag 8)

Stel je hebt een tabel, waarin er 3 (of welk getal ook) rows zijn die foreign keys vormen naar een andere tabel; bijvoorbeeld appel_id, peer_id en banaan_id.

Als in je queries nu die 3 keys steeds samen gebruikt worden bij het joinen naar de respectievelijke tabellen, kan je best 1 index maken op de 3 rows, ipv. 3 verschillende indices. Dat klopt toch, ja? Speelt de volgorde van het tweede en het derde element ook een rol (het eerste element kan je tevens als losse index beschouwen)?

Maar wat als nu bijvoorbeeld appel_id geen foreign key is, maar een gewone primary key van de tabel zelf. Volstaat het om dan een 'groep'-index te maken op alleen peer_id en banaan_id of moet je appel_id opnieuw opnemen in je index, ondanks hij al primary key is?

Hopelijk is het zo duidelijk :)

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 18-08 21:00

Creepy

Tactical Espionage Splatterer

Als je continu selecteert op alle drie de velden tegelijk dan is het het snelst om 1 secundaire index te maken die gebruikt maakt van alle drie de velden.
Dat 1 van die velden nu toevallig ook een primaire sleutel is, of een foreign jey maakt niet uit.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Verwijderd

Topicstarter
Ah oké, bedankt voor de verheldering Creepy :)

Is er eigenlijk een bepaalde strategie voor het kiezen van indices? Als je nu hebt dat 3 velden vaak voorkomen in WHERE-clauses van queries, maar ook soms slechts 2 van die 3, hoe kies je dan indices? Ik zou zeggen: ik maak er 2 aan, 1 voor de 3 en een ander voor de 2.

  • Annie
  • Registratie: Juni 1999
  • Laatst online: 25-11-2021

Annie

amateur megalomaan

Verwijderd schreef op 23 August 2003 @ 19:57:
Is er eigenlijk een bepaalde strategie voor het kiezen van indices?
Ja, indices leg je aan op basis van een aantal aannames die je al met een bepaalde zekerheid kan vaststellen tijdens het ontwerp, bijv. een index op een kolom waar veel op gezocht wordt. En daarnaast kan je vaak met testdata en het uitvoeren van de queries ook al het een en ander bijstellen.

En daarna ga je (mits nodig) gegevens uit de praktijk bekijken. Bijvoorbeeld welke queries worden het vaakst uitgevoerd en/of welke hebben de meeste impact op het systeem. En op welke tijdstippen worden queries uitgevoerd en in welke mate. Het kan mij bijvoorbeeld niet zoveel boeien dat een facturatiesysteem 's nachts staat te stampen om wat facturen uit te draaien als er toch niemand hoeft te werken met de database. Maar het wordt een ander verhaal als deze zelfde queries tijdens kantooruren ook worden gebruikt voor rapportages terwijl iedereen gegevens wil invoeren.

Today's subliminal thought is: