Foutieve werkende MySQL queries gevraagd
Ik ga in mijn afstudeerscriptie MySQL naar beneden halen en PostgreSQL aanprijzen. Ik heb al een mooi verhaal gemaakt maar het enige wat ik nog mis is een mooi voorbeeld van wat queries die ver van de SQL standaard afwijken en die echt een error MOETEN geven, maar die het gewoon doen.
Dat mysql geen foutmelding geeft op de volgende data heb ik er al in. '01/01/2008' of '2007/02/29'.
Weten jullie misschien een hele mooie querie hiervoor? of natuurlijk meerdere.
Alvast bedankt!
Gewijzigd op 01/01/1970 01:00:00 door Michael
Kom er maar in PG :D
Gewijzigd op 01/01/1970 01:00:00 door Jacco Engel
En verder zou ik inderdaad pgFrank eens vragen, maar die zal hier ook wel reageren.
Wat ook wel onlogisch is, is dat mysql zich niet aan veld lengtes houdt. Een string van 300 kan makkelijk in een varchar(255) terwijl pgsql een error zal geven.
Robert_Deiman schreef op 10.03.2008 09:53:
Ik hoop dat Frank inderdaad ook even langs komt ja! *bloos* haha. Hij kan het natuurlijk wel waarderen als iemand MySQL terecht zwart wilt maken :)Een verkeerde datum inderdaad is al een goed voorbeeld, daarnaast heb je ook als een string te lang is dat mySQL die wel gewoon inkort, waardoor je data corrupt kan raken.
En verder zou ik inderdaad pgFrank eens vragen, maar die zal hier ook wel reageren.
En verder zou ik inderdaad pgFrank eens vragen, maar die zal hier ook wel reageren.
Hmmm ja die GROUP by fouten. Weet iemand toevallig een voorbeeld hiervan?
Quote:
"als iemand MySQL terecht zwart wilt maken :)"
Mag ik hier even enige onderbouwing op?? Dat je pgFrank2 uit wil hangen is tot daar aan toe, maar hij neemt wel de moeite te onderbouwen over het algemeen
SELECT 'a' || 'b';
geeft: 'ab'
In MySQL staat het echter voor een binaire or:
SELECT 1 || 1;
geeft 1
Quote:
Edit:
Weet niet hoe dit in PostgreSQL is..
Weet niet hoe dit in PostgreSQL is..
Gewijzigd op 01/01/1970 01:00:00 door Terry
Een foute GROUP BY:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
SELECT
voornaam,
achternaam,
COUNT(achternaam) AS aantal
FROM
users
GROUP BY
achternaam
voornaam,
achternaam,
COUNT(achternaam) AS aantal
FROM
users
GROUP BY
achternaam
En welke voornaam moet de database nu opleveren? Piet of Jan? Ze heten allebei Jansen, daar heb je er 2 van. Dit soort constructies kan gewoon niet.
Het grote probleem met MySQL is, imho, de grote collectie engines. Er is niet één engine die alles kan wat een goede DBMS zou moeten doen. inooDB komt daar nog het dichts in de buurt. Maar, je bent menselijk en maakt tijdens het bouwen van je database een foutje (toch een MyISAM-tabel) en jouw hele database wordt een onbetrouwbare bak ellende. Dat weet je nog niet, maar de transacties die jij heel veilig in jouw systeem opneemt, blijken dankzij de MyISAM-tabel helemaal niet te werken! Je krijgt hier wederom geen foutmelding op, je bent gewoon weer eens een deel van je data kwijt. Mocht je de mogelijkheid hebben, schakel alle engines uit, behalve innoDB. Dan kun je dit soort fouten niet maken.
Dat is eigenlijk hét probleem van MySQL: Je maakt een fout, niets menselijks is je vreemd, alleen blijkt het dan direct een kapitale fout te zijn. Het gebruik van transactions is erg tricky in MySQL, wanneer je een data definition query in je transaction gebruikt (zie de handleiding), wordt er eerst een COMMIT gegeven. Jouw hele transactie wordt hiermee dus waardeloos, met een beetje pech wordt de de data in jouw database ook waardeloos. MySQL laat geen enkele ruimte voor fouten, jij moet alles goed doen, de database zal zelden een foutmelding geven. Dé meerwaarde van een DBMS zit hem in het beschermen van jouw data en het kunnen herstellen van jouw fouten. Dat gaat vaak alleen niet in MySQL, die ondersteunt dit 9 van de 10x niet. En dat is nergens voor nodig, andere (echte?) DBMS-en ondersteunen dit wil, ook al wil menig MySQL-fanboy dat niet horen.
Dan jouw afstudeeropdracht: Het is niet nodig om MySQL zwart te maken of neer te halen, dat doet MySQL zelf wel. Wat je wel kunt doen, is laten zien wat de verschillen zijn tussen een standaard- en strict-geconfigureerde MySQL-database en een standaard PostgreSQL-database. Al zou je i.p.v. PostgreSQL ook DB2,m FireBird of Oracle kunnen nemen, dat maakt niet zo heel veel uit.
En zoals al vaker is gezegd, MySQL is alleen geschikt voor de échte kenners, de echte specialiseren en dan alleen die kenners en specialisten die nooit een fout maken. Ik moet ze nog tegenkomen...
Ps. Systeemontwikkeling in bv. PostgreSQL is goedkoper dan in MySQL, je bent minder tijd kwijt met debuggen. Wat een vast onderdeel van het bouwen is.
Pps: Vrijwel alle fouten en gebreken van MySQL staan keurig beschreven in de handleiding, het is functionaliteit! Dat je er geen drol aan hebt dat jouw data naar de bliksem is, dat is jouw probleem. MySQL heeft het keurig beschreven.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Jacco schreef op 10.03.2008 10:21:
Mag ik hier even enige onderbouwing op?? Dat je pgFrank2 uit wil hangen is tot daar aan toe, maar hij neemt wel de moeite te onderbouwen over het algemeen
Quote:
"als iemand MySQL terecht zwart wilt maken :)"
Mag ik hier even enige onderbouwing op?? Dat je pgFrank2 uit wil hangen is tot daar aan toe, maar hij neemt wel de moeite te onderbouwen over het algemeen
zie Frank ;)
@pgFrank: Thanks!! Ik ga zeker een gedeelte gebruiken voor mijn scriptie.
Quote:
zie Frank ;)
Ik vraag jou motivatie om die uitspraak te doen. Dat je moet steunen op de mening van Frank geeft mij de indruk dat je maar half weet waar je het over hebt. Ik hoop voor je dat het niet zo is anders kon je scriptie wel eens iets minder geslaagd worden
O ja niet vergeten frank/forum op te nemen in de refferenties/bronvermelding he :P
in je update query je waardes scheiden door "AND" ipv een komma levert geen fouten op in MySQL en veranderd je data gewoon in een 0... weg data!
(was een wedstrijd waarin je in 2 dagen zonder resources een bepaalde opdracht moest doen, ben uiteindelijk 3e geworden)
Jacco schreef op 10.03.2008 11:36:
Mee eens, ik heb ook mijn twijfels over jouw database-kennis. De group by doet mij ook vermoeden dat je nog wel uitdagingen hebt liggen bij wiskunde, de verzamelingenleer.Dat je moet steunen op de mening van Frank geeft mij de indruk dat je maar half weet waar je het over hebt.
Zorg dat je hier voldoende vanaf weet, anders loop je grote kans dat je jezelf voor schut zet met jouw MySQL-afzeik verhaal. Zorg dat je de handleidingen van MySQL en PostgreSQL uitstekend kent en dat je snel en eenvoudig kunt uitleggen wat een GROUP BY is en moet doen wanneer je een aggregate functie gebruikt. Dan is het namelijk ook logisch waarom het gegeven voorbeeld niet kan. Niet kunnen om het niet kunnen, daar stinkt niemand in.
Edit:
@Ypma: Da's een leuke! PostgreSQL geeft de volgende melding:
Quote:
ERROR: argument of AND must be type boolean, not type integer
SQL status:42804
SQL status:42804
In MySQL gaat het inderdaad 'goed', een 0 is het resultaat.
Zal eens uitzoeken waar dit nu weer vandaan komt... Het staat ongetwijfeld in de handleiding.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
pgFrank schreef op 10.03.2008 11:43:
Zorg dat je hier voldoende vanaf weet, anders loop je grote kans dat je jezelf voor schut zet met jouw MySQL-afzeik verhaal. Zorg dat je de handleidingen van MySQL en PostgreSQL uitstekend kent en dat je snel en eenvoudig kunt uitleggen wat een GROUP BY is en moet doen wanneer je een aggregate functie gebruikt. Dan is het namelijk ook logisch waarom het gegeven voorbeeld niet kan. Niet kunnen om het niet kunnen, daar stinkt niemand in.
Jacco schreef op 10.03.2008 11:36:
Mee eens, ik heb ook mijn twijfels over jouw database-kennis. De group by doet mij ook vermoeden dat je nog wel uitdagingen hebt liggen bij wiskunde, de verzamelingenleer.Dat je moet steunen op de mening van Frank geeft mij de indruk dat je maar half weet waar je het over hebt.
Zorg dat je hier voldoende vanaf weet, anders loop je grote kans dat je jezelf voor schut zet met jouw MySQL-afzeik verhaal. Zorg dat je de handleidingen van MySQL en PostgreSQL uitstekend kent en dat je snel en eenvoudig kunt uitleggen wat een GROUP BY is en moet doen wanneer je een aggregate functie gebruikt. Dan is het namelijk ook logisch waarom het gegeven voorbeeld niet kan. Niet kunnen om het niet kunnen, daar stinkt niemand in.
hehe, Met mijn sql kennis is niks mis hoor. Ik heb alleen geen verstand van wat er in MySQL voor foutieve queries gebruikt kunnen worden. Ik doe ze meestal gewoon goed ;)
Ik moet alleen een 1 A4tje hebben, waarom er PostgreSQl gekozen is ipv MySQL. En dat heb ik nu en ik kan het makkelijk onderbouwen. Dus voor lul zal ik niet staan om deze redenen :)
@Jacco: Waarom zou ik het er nog een keer plaatsen als Frank het al heeft gezegd? Ik zei in de beginpost dat ik al een verhaal heb alleen moet ik nog een goede voorbeeld query die ik 1 op 1 kan copy/pasten.
Dit topic wil ik niet gebruiken om MySQL of PostgreSQL aan te prijzen of iets dergelijks, want dat heb ik niet nodig :)
Gewijzigd op 01/01/1970 01:00:00 door michael
Ik heb dit gehad met een sms systeem. Elk nummer had hetzelfde onlogische nummer. Dit kwam omdat er een telfoutje gemaakt was voor de lengte (het zou eerst 6.... en werd 316...
Quote:
Waarom zou ik het er nog een keer plaatsen als Frank het al heeft gezegd?
Omdat ik om jou mening vroeg, als ik die van frank wil weten vraag ik het hem wel maar het feit dat je je eigen mening niet wil of kan formuleren zegt mij voldoende over je motivatie/kennis.
Zoals ik al zei succes met je scriptie.
Code (php)
1
SELECT 1::bool AND 0::bool;
Dit levert in dit geval een fraaie false op.
In MySQL kun je dit doen:
Code (php)
1
SELECT 1 AND 'tekst';
Wat een 0 (false) oplevert.
Zo kan wederom een foutje van de gebruiker tot onverwachte resultaten leiden, je krijgt namelijk wel een resultaat retour. Dat het resultaat niet kan (integer en text in een booleaanse vergelijking), dat is weer eens wat anders....
Edit: Het staat ook gewoon in de handleiding:
Quote:
Note that MySQL evaluates any non-zero or non-NULL value to TRUE. For example, the following statements all assess to TRUE:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
mysql> SELECT 10 IS TRUE;
-> 1
mysql> SELECT -10 IS TRUE;
-> 1
mysql> SELECT 'string' IS NOT NULL;
-> 1
-> 1
mysql> SELECT -10 IS TRUE;
-> 1
mysql> SELECT 'string' IS NOT NULL;
-> 1
Je hebt dus 0 en NULL om FALSE te selecteren, alle andere waardes zijn automatisch TRUE.
In PostgreSQL heb je TRUE, FALSE en NULL, een 0 of 1 moet je typecasten naar een boolean om er wat mee te kunnen doen. 'true' en 'false' (dus tussen quotes, als een string) kun je ook typecasten naar een boolean:
Code (php)
1
SELECT 'true'::bool AND 'false'::bool;
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Jacco schreef op 10.03.2008 12:15:
Omdat ik om jou mening vroeg, als ik die van frank wil weten vraag ik het hem wel maar het feit dat je je eigen mening niet wil of kan formuleren zegt mij voldoende over je motivatie/kennis.
Zoals ik al zei succes met je scriptie.
Ik heb inderdaad geen motivatie om mijn mening hier neer te zetten nee :)Quote:
Waarom zou ik het er nog een keer plaatsen als Frank het al heeft gezegd?
Omdat ik om jou mening vroeg, als ik die van frank wil weten vraag ik het hem wel maar het feit dat je je eigen mening niet wil of kan formuleren zegt mij voldoende over je motivatie/kennis.
Zoals ik al zei succes met je scriptie.