[MySQL] Index op date field

[Verwijderd]

Op een date field (YYYY-MM-DD) heb ik op het moment een gewone index staan om sorteren op datum sneller te maken.
Nu wil ik echter sorteren op maand en dag en het jaar erbuiten laten.
De query hiervoor heb ik al af het enigs probleem is dat hij geen gebruik kan maken van de index (begin valt immers weg).
Nu zou ik dit op kunnen lossen door er een fulltext index op te plaatsen alleen het gaat hier om een InnoDB tabel en fulltext wordt dus niet ondersteund.
Verder zat ik nog te denken aan jaar, maand en dag apart op te slaan en dan een gezamelijke index. Alleen dit is niet echt de mooiste oplossing en ik weet niet zeker of een gezamelijk index wel wordt gebruikt als je 1 van de velden ervan niet gebruikt (jaar).

Dus, wat is de beste manier om een index op een date veld te plaatsen als je het jaar negeert.

[whoami]

Verder zat ik nog te denken aan jaar, maand en dag apart op te slaan en dan een gezamelijke index. Alleen dit is niet echt de mooiste oplossing en ik weet niet zeker of een gezamelijk index wel wordt gebruikt als je 1 van de velden ervan niet gebruikt (jaar).

Dit is de beste oplossing denk ik; dag, maand en jaar in een aparte column bewaren.
Echter, bedenk je wel: is het wel nodig om dit zo te doen; gaan m'n performance er daadwerkelijk serieus op vooruit ? Als je een samengestelde index op deze 3 velden legt, dan kan die enkel gebruikt worden, als je ook 'het begin' gebruikt.
Bv, een samengestelde index op (dag, maand, jaar), kan niet gebruikt worden als je enkel op maand sorteert. Wel als je op dag en maand sorteert.
Ik zou echter ook nog altijd de datum op de gewone manier opslaan, en deze 3 velden enkel gebruiken voor performance-doeleinden mocht dit echt nodig zijn.

[Verwijderd]

Het gescheiden opslaan lijkt mij ook de beste oplossing. Je kunt dan twee indexen maken, één samengestelde index (jaar, maand, dag) voor het sorteren op datum en één index (maand) voor het sorteren op maand.

Nadelen zijn dat het meer ruimte in beslag neemt op disk, langer duurt om data te updaten/inserten en je wat data gerelateerde SQL functionaliteit mist (mocht je die willen gebruiken).

whoami schreef op maandag 02 oktober 2006 @ 12:03:
gaan m'n performance er daadwerkelijk serieus op vooruit ?

Bij een grote set data die gesorteerd moet worden op de maand lijkt het me niet interessant om lineair door de index danwel data te lopen. Maar het is wel afhankelijk van de grote van de data set en de frequentie van een dergelijke query t.o.v. de update/insert queries.

[whoami]

Bij een grote set data die gesorteerd moet worden op de maand lijkt het me niet interessant om lineair door de index danwel data te lopen. Maar het is wel afhankelijk van de grote van de data set en de frequentie van een dergelijke query t.o.v. de update/insert queries.

Vandaar dat ik vraag stelde.

Nadelen zijn dat het meer ruimte in beslag neemt op disk, langer duurt om data te updaten/inserten en je wat data gerelateerde SQL functionaliteit mist (mocht je die willen gebruiken).

Tja, die overhead zal wel beperkt zijn. Indien je DBMS het toelaat, kan je gewoon een Trigger maken die uitgevoerd wordt bij update/insert, en die indien de datum gewijzigd is, die 3 columns gaat gaan bijwerken. De overhead zal wel meevallen.
Over het verliezen van datum-functionaliteit: die verlies je niet als je ook nog je datetime veld behoud.

[curry684]

Verwijderd schreef op maandag 02 oktober 2006 @ 11:58:
Op een date field (YYYY-MM-DD) heb ik op het moment een gewone index staan om sorteren op datum sneller te maken.
Nu wil ik echter sorteren op maand en dag en het jaar erbuiten laten.
De query hiervoor heb ik al af het enigs probleem is dat hij geen gebruik kan maken van de index (begin valt immers weg).
Nu zou ik dit op kunnen lossen door er een fulltext index op te plaatsen alleen het gaat hier om een InnoDB tabel en fulltext wordt dus niet ondersteund.
Verder zat ik nog te denken aan jaar, maand en dag apart op te slaan en dan een gezamelijke index. Alleen dit is niet echt de mooiste oplossing en ik weet niet zeker of een gezamelijk index wel wordt gebruikt als je 1 van de velden ervan niet gebruikt (jaar).

Dus, wat is de beste manier om een index op een date veld te plaatsen als je het jaar negeert.

Wat je zult moeten doen is heel goed analyseren hoe je je data gebruikt. Als dit een van de hoofdtoepassingen is van het betreffende veld ben je definitely beter af om de velden uit te splitsen en zo te onderhouden, dan voldoet de data tenminste aan het doel wat je ermee hebt (ook dat is normaliseren!). Een extra optie is om data in 2 velden uit te splitsen, year en dayofyear, dan kun je met makedate de datum zelf eenvoudig on-the-fly teruggenereren en kun je alsnog binnen het jaar makkelijk sorteren.

Zolang je geen extreem intensieve dingen doet met de feitelijke datetimes is het opsplitsen een efficiente en nette oplossing die conformeert aan je datastructuur.

In een 'echte' database zou je overigens al snel geneigd zijn gewoon een view aan te maken met 3 extra derived columns die day, month en year bevatten, maar helaas hebben we het hier over MySQL

[Verwijderd]

whoami schreef op maandag 02 oktober 2006 @ 14:29:
Vandaar dat ik vraag stelde.

Ik had al een vermoeden .

whoami schreef op maandag 02 oktober 2006 @ 14:29:
Tja, die overhead zal wel beperkt zijn. Indien je DBMS het toelaat, kan je gewoon een Trigger maken die uitgevoerd wordt bij update/insert, en die indien de datum gewijzigd is, die 3 columns gaat gaan bijwerken. De overhead zal wel meevallen.
Over het verliezen van datum-functionaliteit: die verlies je niet als je ook nog je datetime veld behoud.

Ok, ik ging er van uit dat je het datetime veld zou verwijderen om zo redundante informatie uit je tabel te halen. Persoonijk zou ik er namelijk niet voor kiezen om deze informatie dubbel in een tabel te plaatsen.

curry684 schreef op maandag 02 oktober 2006 @ 14:36:
In een 'echte' database zou je overigens al snel geneigd zijn gewoon een view aan te maken met 3 extra derived columns die day, month en year bevatten, maar helaas hebben we het hier over MySQL

Je kunt niet alles hebben in het leven .

[curry684]

Verwijderd schreef op maandag 02 oktober 2006 @ 14:45:
Ok, ik ging er van uit dat je het datetime veld zou verwijderen om zo redundante informatie uit je tabel te halen. Persoonijk zou ik er namelijk niet voor kiezen om deze informatie dubbel in een tabel te plaatsen.

Dat raadt ik ook af, het risico van discrepanties is te groot. En daar in jouw situatie het mogelijk is om een day/month/year combo te gebruiken voor alles wat je wilt zou ik dan voor die vorm van opslag kiezen, en desnoods on the fly datetime teruggenereren waar nodig.

[whoami]

Dat raadt ik ook af, het risico van discrepanties is te groot

Denk dat dit wel meevalt, als je gebruik maakt v/e trigger om die 3 velden op te vullen.

[curry684]

Zijn er mensen die versies van MySQL Live draaien die triggers ondersteunen?