Foutieve werkende MySQL queries gevraagd

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Michael

michael

10/03/2008 09:39:00
Quote Anchor link
Hallo phpers

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
 
PHP hulp

PHP hulp

30/09/2020 07:52:41
 
Jacco Engel

Jacco Engel

10/03/2008 09:46:00
Quote Anchor link
http://phphulp.nl/profiel/user/5193/ <--- Pm die beste man even






Kom er maar in PG :D
Gewijzigd op 01/01/1970 01:00:00 door Jacco Engel
 
Robert Deiman

Robert Deiman

10/03/2008 09:53:00
Quote Anchor link
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.
 
Gerben Jacobs

Gerben Jacobs

10/03/2008 10:09:00
Quote Anchor link
mysql kort strings in?

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.
 
Jurgen assaasas

Jurgen assaasas

10/03/2008 10:10:00
Quote Anchor link
MySQL heeft het geloof ik ook niet zo met GROUP BY op het moment dat je een foutieve groepering maakt.
 
Michael

michael

10/03/2008 10:14:00
Quote Anchor link
Robert_Deiman schreef op 10.03.2008 09:53:
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.
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 :)

Hmmm ja die GROUP by fouten. Weet iemand toevallig een voorbeeld hiervan?
 
Jacco Engel

Jacco Engel

10/03/2008 10:21:00
Quote Anchor link
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
 
Terry

Terry

10/03/2008 10:22:00
Quote Anchor link
In de SQL standaard staat || voor het aan elkaar plakken van twee waardes:

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..
Gewijzigd op 01/01/1970 01:00:00 door Terry
 
Frank -

Frank -

10/03/2008 11:08:00
Quote Anchor link
Gekke fratsen van MySQL kun je hier vinden: klikkerdeklik.

Een foute GROUP BY:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
SELECT
  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 -
 
Michael

michael

10/03/2008 11:33:00
Quote Anchor link
Jacco schreef op 10.03.2008 10:21:
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.
 
Jacco Engel

Jacco Engel

10/03/2008 11:36:00
Quote Anchor link
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
 
M Ypma

M Ypma

10/03/2008 11:38:00
Quote Anchor link
ook een leuke waar ik afgelopen week tegen aanhikte bij SkillsMasters in Ahoy:
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)
 
Frank -

Frank -

10/03/2008 11:43:00
Quote Anchor link
Jacco schreef op 10.03.2008 11:36:
Dat je moet steunen op de mening van Frank geeft mij de indruk dat je maar half weet waar je het over hebt.
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.

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

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 -
 
Michael

michael

10/03/2008 11:50:00
Quote Anchor link
pgFrank schreef op 10.03.2008 11:43:
Jacco schreef op 10.03.2008 11:36:
Dat je moet steunen op de mening van Frank geeft mij de indruk dat je maar half weet waar je het over hebt.
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.

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
 
TJVB tvb

TJVB tvb

10/03/2008 12:06:00
Quote Anchor link
Wat denk je van het invullen van getallen in een database die groter zijn dan eigenlijk mogen.
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...
 
Jacco Engel

Jacco Engel

10/03/2008 12:15:00
Quote Anchor link
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.
 
Frank -

Frank -

10/03/2008 12:53:00
Quote Anchor link
Het probleem van Ypma ontstaat doordat MySQL geen poging doet om booleans af te dwingen bij logische vergelijkingen AND, OR en XOR. In PostgreSQL ben je verplicht om de input te casten:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
SELECT 1::bool AND 0::bool;

Dit levert in dit geval een fraaie false op.

In MySQL kun je dit doen:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
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)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
mysql> SELECT 10 IS TRUE;
-> 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)
PHP script in nieuw venster Selecteer het PHP script
1
SELECT 'true'::bool AND 'false'::bool;
Gewijzigd op 01/01/1970 01:00:00 door Frank -
 
Michael

michael

10/03/2008 23:02:00
Quote Anchor link
Jacco schreef op 10.03.2008 12:15:
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.
Ik heb inderdaad geen motivatie om mijn mening hier neer te zetten nee :)
 



Overzicht Reageren

 
 

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.