COLUMN: Backticks in SQL-Queries

Door Eddy B, 15 jaar geleden, 14.132x bekeken

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

  1. COLUMN: Backticks in SQL-Queries

 

Er zijn 17 reacties op 'Columns'

PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Elwin - Fratsloos
Elwin - Fratsloos
15 jaar geleden
 
Toch een paar opmerkingen. Ten eerste noem je in je alinea over de gevaren PHPMyAdmin een database. Ik neem aan dat je dat niet bedoelde?

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/
- SanThe -
- SanThe -
15 jaar geleden
 
Quote:
Niet alle databases ondersteunen het gebruik van backticks. PhpMyAdmin bijvoorbeeld wel, en SQLserver niet.


PhpMyAdmin is GEEN database, maar een tooltje.
Eddy B
Eddy B
15 jaar geleden
 
0 +1 -0 -1
@Elwin en SanThe: Inderdaad een foute formulering, sorry daarvoor, ik heb het aangepast.

@SanThe: Een tooltje? Haha ;)

@Elwin: Bedankt voor je toevoeging aan het column.
Jacco Brandt
Jacco Brandt
15 jaar geleden
 
0 +1 -1 -1
Ik vind dat je in MySQL best backticks kunt gebruiken, ze zorgen namelijk voor overzicht. Het gebruik van backticks neemt echter niet weg dat je overzichtelijke kolomnamen moet gebruiken (dus niet de voornaam & achternaam).

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?
Elwin - Fratsloos
Elwin - Fratsloos
15 jaar geleden
 
Waarom zorgen backticks voor overzicht?
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.
Jacco Brandt
Jacco Brandt
15 jaar geleden
 
Ik weet niet wat voor font jouw IDE gebruikt, maar de mijne maakt een duidelijk onderscheid tussen backticks en single quotes.

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.
Kees Schepers
kees Schepers
15 jaar geleden
 
0 +1 -0 -1
Quote:
Als je een gevorderde PHP'er bent wist je het al, een database heeft gereserveerde veldnamen.


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 :)
Eddy B
Eddy B
15 jaar geleden
 
0 +1 -0 -1
Kees, het is aangepast. Bedankt. :)
Aad B
Aad B
15 jaar geleden
 
@Jacco: Ik heb al heel wat gemigreerd van database engine A naar database engine B maar nog nooit enig gemak gehad van die smerige backtics, eerder ongemak. Ikzelf scherp de regel toch wel strakker aan: Bij ons worden nooit backtics gebruikt en er worden nooit reserved words gebruikt voor veldnamen, attribute, kolomnamen, tabelnamen whatever, nooit!
- Jim  -
- Jim -
15 jaar geleden
 
Zoals ik het hier lees, maak ik er uit op dat backticks in veldnamen gebruikt worden...
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.
Ger van Steenderen
Ger van Steenderen
15 jaar geleden
 
0 +1 -0 -1
Ik kan heel goed begrijpen dat in phpmyadmin backticks worden gebruikt, zij hebben namelijk niet de controle over de opbouw van een database.
Martijn Wieringa
Martijn Wieringa
15 jaar geleden
 
Ik ben het eens met Jacco

Quote:
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 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.
Jacco Brandt
Jacco Brandt
15 jaar geleden
 
En daarbij is order een heel fatsoenlijke kolomnaam.
Ger van Steenderen
Ger van Steenderen
15 jaar geleden
 
Dat ben ik niet met je eens. Je gaat in PHP toch ook geen functie maken die echo genaamd is?
Jacco Brandt
Jacco Brandt
15 jaar geleden
 
Nee, ik zie daar namelijk geen nut van in.
Ravi van rooijen
Ravi van rooijen
13 jaar geleden
 
0 +1 -0 -1
Ik vind het overzichtelijk

Ik ben het dus eens met Martijn
PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Jeroen VD
Jeroen VD
13 jaar geleden
 
waarom je een topic van twee jaar oud bumpt met zon nietszeggende reactie snap ik niet.

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.

Inhoudsopgave

  1. COLUMN: Backticks in SQL-Queries

Labels

PHP tutorial opties

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.