Onderwerp: MySQL 5.0.x instellingen

Beste WHTérs,

als ik MySQL queries wil laten draaien zoals:

PHP Code:

DELETE FROM messages WHERE read='1' 


krijg ik een leuke error:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'read='1'' at line 1

als ik

PHP Code:

DELETE FROM messages WHERE `read`='1' 


dan krijg ik wel een goed resultaat.

Dit ligt mogenlijk aan een instelling binnen MySQL weet iemand waar of hoe of heeft iemand hier ooit eerder problemen met gehad?

heb ik nog nooit gehad, al geprobeerd met:

PHP Code:

DELETE FROM messages WHERE read = '1'; 


#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'read = '1'' at line 1

Code:

DELETE FROM messages WHERE read = 1;

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'read = 1' at line 1

Welke MySQL versie draai je?

read is een reserved word

http://dev.mysql.com/doc/refman/5.0/...ved-words.html

gebruik rond veldnamen bij mysql altijd `naam` de ` zo voorkom je dat je functies aanroept.

Klopt alleen er word nogal fel beweerd dat dit "gevaarlijk" kan zijn?
Terwijl ik toch netjes al mijn variabeltjes beveilig voor ik ze in de query gooi

Prefix je kolomnamen met bijvoorbeeld de tabelnaam en je hebt nergens last van. Maakt het ook wel zo overzichtelijk bij grote queries waar de data nou eigenlijk vandaan komt.

Oorspronkelijk geplaatst door gjtje

Prefix je kolomnamen met bijvoorbeeld de tabelnaam en je hebt nergens last van. Maakt het ook wel zo overzichtelijk bij grote queries waar de data nou eigenlijk vandaan komt.

prefixen van kolomnamen moet ik ten stelligste tegenspreken, SQL heeft dit zelf voorzien. Zorg gewoon dat je altijd in je where/order/... de volledige aanduiding geeft:

Code:

mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> create table testtable(`read` varchar(50));
Query OK, 0 rows affected (0.09 sec)

mysql> insert into testtable values('string 1');
Query OK, 1 row affected (0.00 sec)

mysql> insert into testtable values('string 2');
Query OK, 1 row affected (0.00 sec)

mysql> select * from testtable where read like '%2%';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'read like '%2%'' at line 1

mysql> select * from testtable where testtable.read like '%2%';
+----------+
| read     |
+----------+
| string 2 | 
+----------+
1 row in set (0.00 sec)

Als je gaat prefixen krijg je gedrochten als testtable.testtable_read; wat enkel leidt tot meer tikwerk en onleesbare queries, terwijl er een oplossing voor is.

Elk goed framework of query-builder-library zou dit ook voor jou moeten doen.

Oorspronkelijk geplaatst door wonko

Als je gaat prefixen krijg je gedrochten als testtable.testtable_read; wat enkel leidt tot meer tikwerk en onleesbare queries, terwijl er een oplossing voor is.

Je queries zijn ook als je ga prefixen prima leesbaar. Jouw voorbeeld aanhalend heb je zeker niet meer tikwerk als je ga prefixen

Zolang de gekozen methode helder en consistent uit wordt gevoerd is het ene noch het andere een probleem.

Het leidt er wel toe dat bvb in Rails of een ander framework dat de structuur uit de database inleest, je al je objecten moet aanspreken met de volledige naam (klantobj.klant_straat of klantobj.klant_gemeente bvb), en dat je inconsistentie krijgt (de verwijzing naar het id van de klant (id in de tabel klanten) in tabel facturen noemt facturen_klant_id, en klant_id in de tabel betalingen noemt betalingen_klant_id; terwijl het wel twee keer hetzelfde is en verwijst naar hetzelfde (klant.klant_id).

Als je databases hebt met enkele 10-tallen tabellen, en daarin enkele 10-tallen rijen per tabel ga je al snel afstappen van dergelijke constructies, dan is het handig dat alles gewoon noemt wat het is (straat, gemeente, klant_id) en ondubbelzinnig is.

Als rails of een ander framework dat de database inleest niet de mogelijkheid biedt een degelijke mapping op te geven van kolomnamen en properties dan moet dat framework zo snel mogelijk worden verboden.
Dan ben je ook lekker database onafhankelijk aan het programmeren. Verandert er iets aan je tabel moet je overal je object aanroepen gaan aanzitten passen. Hoe je kolomnamen heten of in welke tabel een object staat zou volledig transparent moeten zijn voor de applicatie.

er zijn mogelijkheden om de mappings te doen, maar dan ga je nog altijd je mappings telkens moeten aanpassen als je DBA beslist om nog maar eens je namen aan te passen. En geef toe dat het eenvoudiger is geen mappings, of slechts enkele uitzonderingen te moeten opgeven dan elke mogelijke naam te moeten gaan mappen naar zijn origineel.

Het gebruiken van de kolomnaam via een ActiveRecord-wrapper is niet geheel ongewoon; anders moet je wel beweren dat frameworks zoals symfony, rails, cake, django,... allemaal verkeerd zijn?

Wanneer de DBA verschuivingen gaat doen, kan hij ook nog altijd voor een goede view zorgen die de originele code niet breekt.