mysql: query naar index met letter vooraf werkt niet

[meneer william]

Beste tweakers,

voor een muziek database heb ik een hiërarchische tabellen structuur met de tabel albums. die heef dan als index a1, a2 etc. als ik de volgende query uitvoer werkt deze niet:

SELECT * FROM albums WHERE index LIKE '%a1%' OR index LIKE '%a2%;

als ik een andere rij met deze methode wil selecteren werkt dat wel bijvoorbeeld:

SELECT * FROM albums WHERE nummers LIKE '%$nummerid[$e]%'

$nummerid[$e] wordt toegewezen door php en dat werkt. als ik deze query op mijn index probeer werkt deze niet. mijn vraag waarom niet?

ik heb me het lamlazeres gezocht naar waar dit aan licht en waar ik de fout maak. ook heb ik geprobeerd om de index te veranderen in een varchar maar phpmyadmin staat dit niet toe.

hier de tabel: http://217.121.76.24:8080/afbeeldingen/tabel.PNG
de tabellen structuur: http://217.121.76.24:8080/afbeeldingen/structuur.PNG
en de error: http://217.121.76.24:8080/afbeeldingen/error.PNG

graag zou ik een kort en bondig antwoord hebben wat ik verkeerd doe. en als er iemand is die me de juiste richting kan in sturen zou dat ook fijn zijn. in de MySQL documentatie kan ik hierover niks vinden ik weet dan ook niet echt waar ik op moet zoeken. ik vind het heel raar en de oplossing licht vast voor de hand. als ik in de index alleen nummers gebruik werkt het namelijk wel gewoon. maar toch wil ik weten waarom het niet werkt als ik er een a voor plak.

ps,

op de screenshots is geen index gedefinieerd deze had ik verwijdert in de hoop dat dit zou werken.

[MueR]

Index is een reserved word. Daarbij: doe jezelf een lol en volg een cursus database ontwerp. Je gebruikt geen table indexes, je hebt geen fatsoenlijke normalisatie, gebruikt reserved words als column names.. Dit is geen goed database ontwerp.

[ Voor 79% gewijzigd door MueR op 03-05-2012 15:01 ]

[xehbit]

Hier een lijstje met woorden die reserved zijn
http://dev.mysql.com/doc/refman/5.5/en/reserved-words.html

Verder kan je beter auto-incerment gebruiken op je index, in je tabel

[ Voor 57% gewijzigd door xehbit op 03-05-2012 15:03 ]

[NMe]

Not to mention dat een LIKE die begint met een wildcard geen table-indices kán gebruiken in MySQL en het hele zaakje dus niet gaat kunnen performen. Lees je inderdaad asjeblieft in wat betreft normalisatie, want dit gaat nergens heen. Je hebt niet eens een primary key...

[ Voor 7% gewijzigd door NMe op 03-05-2012 15:05 ]

[meneer william]

als ik het goed heb mag ik dus de rij gewoon geen index noemen. ik zal dat even proberen. en ja hoor dat werkt nog rest iik met de vraag waarom mag een index niet met letter beginnen. heel veel indexen van webshops etc. hebben producten met een index die beginnen met een letter. hoe zit dit eigenlijk?

[MueR]

Ik zal mezelf nog eens herhalen: volg een cursus databaseontwerp. Het feit dat een productcode met een letter begint is irrelevant, dat is vrijwel zeker niet de primary key op de tabel.

[RMX]

Gewoon je query opbouwen met backticks.

code:

 where `index` LIKE

[MueR]

RMX schreef op donderdag 03 mei 2012 @ 15:13:
Gewoon je query opbouwen met backticks.

code:

 where `index` LIKE

Nee, doe dat nou niet. Het is gewoon onhandig om reserved words als column/index name te gebruiken, leer dat nou niet aan.

[ Voor 5% gewijzigd door MueR op 03-05-2012 15:14 ]

[NMe]

Niemand heeft gezegd dat een index niet met een letter mag beginnen, het is alleen bijzonder onpraktisch. Een identifier (index is heel iets anders) moet uniek zijn en een auto incrementing integer is dan veruit de meest logische keuze. Een LIKE gebruiken terwijl je eigenlijk een = nodig hebt is al helemaal zinloos, en een LIKE doen die begint met een % (wildcard dus) is helemaal onhandig omdat je geen échte indexes kan gebruiken waardoor al je query's langzamer worden. Volg asjeblieft de raad van MueR op en stop voor even met wat je aan het doen bent en lees éérst een cursusje door, want dit gaat je opbreken. Is het niet nu, dan is het volgende week of over een maand.

RMX schreef op donderdag 03 mei 2012 @ 15:13:
Gewoon je query opbouwen met backticks.

code:

 where `index` LIKE

Nee, want index is een feitelijk incorrecte naam en hem op die manier tóch gebruiken is dus niet handig. Het is geen index maar een id(entifier). Backticks gebruiken als je een tabel "User" wil noemen is natuurlijk wel acceptabel.

[meneer william]

je hebt gelijk ik zal een cursus normalisatie moeten doen. om eerlijk te zijn heb ik tot nu toe gewoon phpmyadmin gebruikt om query's voor me te maken. ook heb ik het maken van een index in phpmyadmin nooit begrepen zo als ik het deed werkte het gewoon.

maar goed het werkt nu ik de rij hernoemt heb naar ID. http://217.121.76.24:8080/afbeeldingen/querylukt.PNG

ik zal zo als jullie mij aanraden jullie wijze raad opvolgen en kijken hoe ik de index beter kan opbouwen de reden dat ik geen AUTO_INCREMENT gebruik is omdat ik zelf de index opbouw vanuit php. daarbij had ik er een letter voorgezet omdat deze index ook in andere tabellen gebruikt wordt als koppeling zie mijn normalisatie plan.

http://217.121.76.24:8080...ormalisatie%20ontwerp.pdf

maar jullie hebben mijn ogen geopend ik dacht zet er een letter voor dat is handiger maar met AUTO_INCREMENT en de afschijding van de tabel zelf is alles al uniek. ik zal dat gaan gebruiken en vervolgens de juiste query's gebruiken.

bedankt voor de moeite ik weet nu welke kant ik op moet.

[ Voor 49% gewijzigd door meneer william op 03-05-2012 15:28 ]

[Martijn19]

meneer william schreef op donderdag 03 mei 2012 @ 15:18:
je hebt gelijk ik zal een cursus normalisatie moeten doen.

Om MueR nog maar eens te herhalen, lees je in over database ontwerp. Normalisatie is een proces in het ontwerpen van je database

[MueR]

meneer william schreef op donderdag 03 mei 2012 @ 15:18:
de reden dat ik geen AUTO_INCREMENT gebruik is omdat ik zelf de index opbouw vanuit php

Fout - zoekwoord: concurrent inserts

daarbij had ik er een letter voorgezet omdat deze index ook in andere tabellen gebruikt wordt als koppeling

Fout - zoeken op een string is altijd langzamer, numeriek gaat stukken sneller

Nog een paar zoekwoorden/tips: koppeltabel, gebruik de data-types van je database ("24-12-2012" is geen datum)

[NMe]

Om even te illustreren waarom ID's genereren uit PHP (of een andere taal) niet handig is:

Voeg een record in. De tabel was leeg, dus de id van dat record wordt 1.
Voeg nog een record in. Het hoogste id in de tabel is 1, dus het nieuwe id wordt 2.
Haal het tweede record weg.
Voeg nog een record in. Het hoogste id in de tabel is 1, dus het nieuwe id wordt wéér 2.

Dit is in een simpel databaseje zoals deze geen groot probleem, maar je kan je vast voorstellen dat je geen twee facturen wil hebben met hetzelfde id en alle problemen van dien.