[MySQL] Query optimalisatie gevraagd

[LuCarD]

Ik heb de volgende tabel

table personeel
username varchar(50) unique index
additional set
.
.
.

Nu heb ik een username en ik wil een selectie doen van de username en de volgende en vorige in de lijst, geordend op username. Daarbij moet nog worden voldaan aan een waarde uit de set.

dus ik heb deze query

code:

SELECT
  a.username, b.username, c.username 
FROM 
  personeel b 
LEFT JOIN personeel a ON
  a.username > b.username and a.additional like '%WAARDE%'
LEFT JOIN personeel c ON
  c.username < b.username and c.additional like '%WAARDE%'
WHERE 
  b.username = 'lucard' and b.additional like '%WAARDE%' 
ORDER BY 
  a.username asc, c.username desc 
LIMIT 1

Het is een mysql 3.x database anders had ik volgens mij wel een union kunnen gebruiken...

[HenkS]

advies: pak een boek of site die iets verteld over normaliseren....

[LuCarD]

Op woensdag 06 maart 2002 16:28 schreef HenkS het volgende:
advies: pak een boek of site die iets verteld over normaliseren....

Wat zou jij dan verder willen normaliseren op additional na dan?

[Pelle]

Op woensdag 06 maart 2002 16:30 schreef LuCarD het volgende:
Wat zou jij dan verder willen normaliseren op additional na dan?

Ja dat snap ik ook niet... ik tel hier maar 1 tabel en 2 velden.. mag jij mij uitleggen hoe je dat normaliseert

[LuCarD]

Op woensdag 06 maart 2002 16:37 schreef Pelle het volgende:

[..]

Ja dat snap ik ook niet... ik tel hier maar 1 tabel en 2 velden.. mag jij mij uitleggen hoe je dat normaliseert

Je zou in principe het veld additional kunnen normaliseren, maar of dat wenselijk is?

additional is namelijk een set veld en die heeft een aantal vaste mogelijkheden... (hmm bij nader inzien is dat al geheel normaal )

ipv een extra tabel is er namelijk een extra interne tabel gedefineerd (de set)

[Verwijderd]

Ik vertel
Jij vertelt
Wij vertellen

een boek vertelddddddd

sorry... geen zinnige reactie dit...

[Pelle]

Op woensdag 06 maart 2002 16:42 schreef LuCarD het volgende:
(hmm bij nader inzien is dat al geheel normaal )

Ik wou net zeggen ja

Maar wat is je probleem precies met deze query? Te langzaam? Of heb je het idee dat 'ie makkelijker kan? Ik zie niet in waarom je dit niet zou gebruiken namelijk.

[D2k]

Op woensdag 06 maart 2002 16:45 schreef samba het volgende:
Ik vertel
Jij vertelt
Wij vertellen

een boek vertelddddddd

sorry... geen zinnige reactie dit...

laat um dan voortaan weg ajb.......

[LuCarD]

Hij is snel doordat de limit er op zit.

Maar als de limit er niet zou zijn dan returned hij een selectie van #row (die a matcht) * #row (die b matcht).

En een limit werkt pas na de order by dus er wordt eerst een complete temptabel gemaakt om de order by te regelen en daarvan word row 1 dan teruggegeven.

Nu is de tabel maar 100 records maar als hij zometeen groter wordt word hij volgens mij dus ook exponetieel langzamer.

Dus wat kan ik het beste doen. Deze query houden of twee losse queries?

[whoami]

Trouwens, uw datamodel normaliseren zal er niet voor zorgen dat uw query daardoor performanter wordt. In tegendeel. Vaak wordt er een beetje gedenormaliseerd om queries wat sneller te laten verlopen. (Dan heb je minder joins nodig ed).

[Grum]

Joins zijn juist snel op velden met GOEDE indices.

Je doet ook alleen maar joins om minder meer relevante/minder irrelevante informatie op te halen dan dat je normaal zou doen. Doe je het daar niet voor ? dan is je datamodel brak