COLUMN: Backticks in SQL-Queries
De afgelopen 2 weken lees ik op PHPhulp.nl vaak discussies over de zogenaamde 'backticks' in queries. Eigenlijk best logisch, aangezien nergens echt duidelijk wordt uitgelegd waarom backticks wel of niet moeten worden gebruikt in queries.
Gereserveerde Veldnamen
Als je een gevorderde PHP'er bent wist je het al, een MySQL database heeft gereserveerde woorden, die je niet mag gebruiken in veldnamen of tabelnamen. Namen zoals 'order', 'key' en 'drop', deze namen gebruikt de database intern en om verwarring - of errors - buiten de deur te houden mogen die namen niet worden gebruikt in queries.
Backticks
Maar wat nou als je echt een veld moet uitlezen met de naam 'order'? Dan kan je overwegen backticks te gebruiken in je query. Dat is een van de handige opties die backticks je geven.
Laten we zeggen, dat we de volgende query hebben:
SELECT 'id', 'naamenachternaam', 'nogeenveld'
De veldnamen zijn nu bijna onleesbaar doordat er geen onderscheid word gemaakt tussen woorden. Backticks geven je de optie spaties en andere alternatieve tekens te gebruiken in je query.
Bijvoorbeeld:
SELECT `id`, `naam & achternaam`, `nog een veld`
Nu is het dus mogelijk spaties, komma's en zelfs een ampersand te gebruiken in je query. Dit lijkt misschien handig, maar in werkelijkheid helpt dit je hele database om zeep. Je verliest gemakkelijk overzicht en in grote CMS systemen is dat niet wenselijk.
Dat betekend natuurlijk niet dat je nooit backticks mag gebruiken in je query. Stel dat je de volgorde van iets wilt opslaan, dan is het makkelijk een veld te gebruiken met de naam 'order', of misschien een bestelling?
Gevaren
De gevaren zijn klein en zelfs onwaarschijnlijk. Niet alle databases ondersteunen het gebruik van backticks. PhpMyAdmin(een database management tool maar desalniettemin) bijvoorbeeld wel, en SQLserver niet. Dit betekent dat overschakelen tussen verschillende databases misschien een probleem kan vormen.
Conclusie
Probeer zo weinig mogelijk gereserveerde woorden te gebruiken in je database en queries, als het echt niet anders kan: gebruik je backticks. Gebruik backticks nooit om onduidelijke veldnamen te kunnen gebruiken zoals 'gebruiker1 en twee', spaties en vreemde tekens horen simpelweg niet in een query.
bron
Gesponsorde koppelingen
Inhoudsopgave
Er zijn 17 reacties op 'Columns'
Verder heb je het, onder andere in je conclusie, er over dat 'als het echt niet anders kan' je backticks kan gebruiken. ik ben nog nooit een situatie tegen gekomen waar ik een gereserveerde naam moest gebruiken voor een kolom (of tabel).
Ik snap best dat 'order' (voor volgorde) een makkelijke naam voor een kolom is, maar er is altijd een manier om het niet als kolom te gebruiken. Bijvoorbeeld (en dat heeft voor veel mensen niet de voorkeur) het gebruik van Nederlandstalige kolommen.
Maar ook in het Engels is het mogelijk om iets anders te verzinnen. Bijvoorbeeld de volgorde van categorieën: cat_order (al zou ik liever cat_sort_id doen).
Hoe kom ik op die naam? Ik gebruik voor alle kolommen een prefix op basis van de naam van de tabel: categorie -> cat_.
Dit heb ik ooit beschreven op mijn site. Nu wil ik zeker niet 'pronken' met mijn site (ooit een migratie van Wordpress fout gegaan), maar de inhoud is er nog wel: http://fratsloos.nl/tutorials/tips-voor-het-opzetten-van-je-database/
-0 
@SanThe: Een tooltje? Haha ;)
@Elwin: Bedankt voor je toevoeging aan het column.
Het enige voordeel wat er dus eigenlijk aan het niet gebruiken van backticks is (naast het meerdere typwerk, wat door een fatsoenlijk script automatisch gaat) het makkelijker migreren naar een database-server van een ander type. Maar, wees eerlijk, wanneer komt het voor dat je van het type database wisselt?
Persoonlijk vindt ik het minder overzichtelijker, omdat backticks, als je snel door een script kijkt, lijken op enkele quotes.
Als je de query op een gestructureerde manier schrijft, dus meerdere regels, gereserveerde woorden en functies in hoofdletters, et cetera, dan heb je volgens mij geen backticks nodig voor de overzichtelijkheid.
Daarbij schrijf ik mijn queries op meerdere regels, met gereserveerde woorden en met de functies in hoofdletters. En toch vind ik het overzichtelijker om met backticks te werken.
Ik zeg niet dat jullie dat ook moeten doen, ik vraag om een beetje begrip voor mensen die het fijner vinden, het is namelijk niet slechter.
-0
Sinds wanneer heeft een database gereserveerde veldnamen? Volgens mij bedoel jij dat een MySQL database reserved words heeft die je niet in veldnamen moet gebruiken tenzij met backticks. Ook zou een referentie naar deze keywords niet onaardig zijn: mysql reserved words.
Dus een duidelijke formulering zou niet weg zijn!
Toch goed dat je het artikel geschreven hebt, zeker voor de mensen die de mysql of mysqli extensie gebruiken. In de bekende ORM frameworks heb je hier geen last van :)
Dat kan niet de bedoeling zijn.
Ik vind dat het gebruik van backticks heel goed gebruikt kan worden binnen PHP-scripts om tabellen en veldnamen van kolommen aan te duiden. (sterker nog, ik doe het altijd!) En dat maakt mogelijk ook een verschil. Als het sporadisch gebruikt zou worden zou ik er denk ik ook jeuk van krijgen. Juist omdat ik het altijd doe (alleen icm MySQL), is het voor mij waardevol geworden. Maar dan dus consequent, altijd.
Dan kan het zeker voor overzicht kan zorgen. Dit sluit een juist ontwerp van een database (en dus de naamgeving van kolommen ook) niet uit.
En tabel of kolom met een naam als "user" kan voorkomen, (al zou je denken in geval van een kolom "userId"), in het ontwerp kan je er ook voor kiezen dit veld "member" te noemen.
Over de discussie Backticks kunnen niet in SQLServer e.d., SQLServer maakt gebruik van brackets...
Dat is dan weer de wijze van SQLServer om backticks te gebruiken. ;)
Als laatse wil ik nog benoemen dat ik moeilijk kan voorstellen dat in geval van bijv. een migratie naar een andere database de bestaande queries uit PHP-scripts gevist moeten worden. Als je gaat migreren neem ik aan dat je ook niet de queries uit PHP-scripts gebruikt.
Conclusie: Ik ben niet tegen backticks, maar wel tegen sporadisch gebruik ervan. Ik ben wel tegen slechte database-designs en onoverzichtelijke (brakke) code.
-0
Ik vind kolomnamen met backticks makkelijker lezen. Ze scheiden (net als single quotes) duidelijk de syntax van waarden.
Soms wel en soms niet een quote of backtick gebruiken staat rommelig. Ik houd van consistente code (waar mogelijk). Met backticks bescherm je tevens je code voor het geval dat er later nieuwe "MySQL Keywords" bij komen.
backticks horen helemaal niet thuis in SQL. ze zijn een trucje om slecht gegeven kolomnamen toch te laten werken, als je ze goede namen geeft heb je ze nooit nodig. wanneer je backticks nodig hebt voor overzicht heb je totaal geen overzichtelijke manier van scripten, ze zorgen juist voor drukte.
zie de rest van deze reacties voor de rest van de uitleg.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu