Bekijk Volledige Versie : MySQL 5.0.x instellingen
Beste WHTérs,
als ik MySQL queries wil laten draaien zoals:
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
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? :X
Ramon Fincken
16/01/08, 20:44
heb ik nog nooit gehad, al geprobeerd met:
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
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/en/reserved-words.html
johan.smits
16/01/08, 23:09
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.
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:
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.
crazycoder
17/01/08, 08:21
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.
crazycoder
17/01/08, 09:09
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 je een beetje aan ga lopen rotzooien wordt het altijd een puinhoop.
Je kan prima klant_klantid facturen_klantid betalingen_klantid hanteren of eventueel afkortingen zoals fact_klantid. De inconsistentie waar jij op doel bestaat naar mijn mening niet.
Een vereiste is dat je database genormaliseerd (eigenlijk altijd noodzakelijk) is en dat je consistent bent in het geven van namen. Ben je dat niet dan vermoed ik dat je altijd de pineut bent :)
Dit werkt ook goed als je met grotere databases werk.
Je manier van werken moet je wellicht aanpassen als de omstandigheden (lees framework) hierom vraagt. Dat wil vanzelfsprekend niet zeggen dat een andere manier van werken per definitie problemen op zou leveren of onjuist is.
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:
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.
Ik vind deze manier van prefixen toch leesbaarder dan die van jou:
SELECT t.* FROM database.testtable t WHERE t.read LIKE '%2%';
Aliases zijn leuk maar bij grote queries onoverzichtelijk en daarnaast kan je de alias niet door de hele query heen gebruiken waardoor het alleen maar nog onoverzichtelijker wordt.
Ik werk voornamelijk met java en .net en daar is dit hele mapping gebeuren netjes uitgewerkt. Het verschilt ook per project wat het best toepasbaar is maar persoonlijk vind ik prefixen een methode die goed werkt en die ook goed te debuggen valt, want dat is ook belangrijk. Zelfs als je een mapper gebruikt wil je wel nog leesbare sql statements overhouden.