Een poging de magie rond MySQL te verwijderen :)

[ACM]

Ik heb ondertussen redelijk wat ervaring met het gebruik van MySQL en ben me gaan ergeren aan een aantal puntjes.
Vaak heb ik in zo'n context dan tegen een vriend en/of collega iets gezegd ala "ik moet er hoognodig es een lijstje van gaan maken". En nadat ik zag dat mysql een varchar-veld auto_increment kan laten definieren ben ik daar toch maar eens aan begonnen

Kortom, weet je iets om toe te voegen. Post het hier
Zie je iets dat in jouw ogen fout is, vraag om uitleg of verbeter de entry

Ik wil geen "maar dat zit straks wel in 4.1" opmerkingen horen, het zit er nu niet in en voorlopig dus ook nog niet
Het 4.0 traject duurde geloof ik ook bijna 2 jaar? En als ik het vandaag wil gebruiken heb ik er niks aan te horen dat het er volgend jaar in zal zitten.

Evt wil ik de lijst ook wel uitbreiden met positieve punten, maar dat ontneemt imho wel de charme ervan

Owja...
De lijst
http://vulcanus.its.tudelft.nl/acm/got/antimysql.php

[ Voor 4% gewijzigd door ACM op 29-03-2003 14:30 ]

[D2k]

(maar dat had ik via icq al gemeld )

[Glimi]

Heren, ik zit niet te wachten op pure rant. Graag onderbouwing bij punten en in reacties zit ik eigenlijk niet op te wachten.

Mocht je het wel nodig vinden te reageren zonder onderbouwing of lekker te gaan ranten, dan kun je consequenties verwachten

[Rickets]

ACM schreef op 29 March 2003 @ 14:28:

Kortom, weet je iets om toe te voegen. Post het hier
Zie je iets dat in jouw ogen fout is, vraag om uitleg of verbeter de entry

Ik wil geen "maar dat zit straks wel in 4.1" opmerkingen horen, het zit er nu niet in en voorlopig dus ook nog niet
Het 4.0 traject duurde geloof ik ook bijna 2 jaar? En als ik het vandaag wil gebruiken heb ik er niks aan te horen dat het er volgend jaar in zal zitten.

Je wilt geen opmerkingen horen in de trant van "dat zit er straks wel in", maar punt 17. Pas sinds heel kort unions e.d. hoort er om een zelfde soort reden ook niet in, vind ik.
Unions zitten erin, je kan het vandaag gebruiken. Of heb ik het mis?

[ Voor 16% gewijzigd door Rickets op 29-03-2003 14:48 ]

[simon]

Misschien mag mysql wel 'buggy' enz. zijn, maar waarom gebruiken jullie dit dan? En waarom is het dan een zo veel gebruikte DBMS, ik denk dat ook nog belangrijk is om te bedenken dat de echte grote DBMS'en wel echt veel geld kosten, en MySQL niet.. Naast al die rariteiten is er nog wel wat goeds

[ACM]

Rickets schreef op 29 March 2003 @ 14:48:
Je wilt geen opmerkingen horen in de trant van "dat zit er straks wel in", maar punt 17. Pas sinds heel kort unions e.d. hoort er om een zelfde soort reden ook niet in, vind ik. Unions zitten erin, je kan het vandaag gebruiken. Of heb ik het mis?

Versie 4.0.12 is net twee weken ofzo stabiel verklaart. En in alle 3.x releases zit het niet. Kortom, nog veel setups met mysql zullen dat nog niet hebben
Dus het is maar de vraag of je het wel kan gebruiken, in principe kan het iig ja

Simon schreef op 29 March 2003 @ 14:48:
Misschien mag mysql wel 'buggy' enz. zijn, maar waarom gebruiken jullie dit dan? En waarom is het dan een zo veel gebruikte DBMS, ik denk dat ook nog belangrijk is om te bedenken dat de echte grote DBMS'en wel echt veel geld kosten, en MySQL niet.. Naast al die rariteiten is er nog wel wat goeds

Euh het is gratis. Het performt best goed met simpele queries. Hoe simpeler de query hoe groter het verschil met andere DB's en dan op een gegeven moment draait het om, hoe complexer de query hoe relatief slechter mysql het doet, Tweakers.net doet voornamelijk (mede opgelegd door het gebruik van mysql zelf) simpele queries. En het is historisch zo gegroeid en toen tweakers.net begon waren de andere producten nog minder bekend dan nu, vooral postgresql heeft de sinds versie 7.0 een flink stel sprongen voorwaarts gemaakt, daarvoor was het niet echt super heb ik begrepen.

Toch denk ik dat MySQL te vaak wordt overgewaardeerd en vandaar ook dat lijstje

[DiNo!]

5. Case-sensitive tabelnamen.

Wat is daar raar aan?, of, waarom zou je dit anders willen?

[Verwijderd]

17. Pas sinds heel kort unions e.d.

Is dat een gemis dat het pas sinds kort in zit?

[Brakkie]

Verwijderd schreef op 29 March 2003 @ 15:48:
[...]

Is dat een gemis dat het pas sinds kort in zit?

Lees het topic eens voor je reageerd....

[Apache]

Unions zit in de stable, maakt niet uit hoe lang het erin zit, dat niet iedereen upgrade ligt niet aan de mensen die aan mysql werken

De ergste vindt ik persoonlijk
2. SELECT 'A' = 'a' levert true op.

hierdoor had ik een der vaagste bugs ooit waar ik ook veel te veel tijd heb ingestoken om ze te tracen, zelfs hele lappe code herschreven en hopen nutteloze debug informatie toegevoegd, maar goed, het is al gefixed

Voor de rest een hele hoop punten die er idd wel mogen zijn. Maar dit zijn ook niet meteen de doelstellingen van MySQL.

Wat is trouwens "de magie" rond MySQL? het is maar een RDBMS ... moest het nu een mooie sprookjes prinses zijn ok

_{Volgens mij heeft captain ahab z'n whale gevonden ....}

[ACM]

DiNo7 schreef op 29 maart 2003 @ 15:37:
Wat is daar raar aan?, of, waarom zou je dit anders willen?

Het is ronduit irritant, zeker omdat je dus blaat, Blaat, BlAat, BLAAT etc als tabellen kan definieren... Op een unix platform that is, op een windows platform weer niet.
Dat verschil is haast nog wel erger dan dat het case-sensitive of niet is.

Daarnaast wijkt het bij mijn weten af van de SQL-specs en doen alle andere databases (die ik ken) netjes case-insensitive tabelnamen.

Apache schreef op 29 maart 2003 @ 16:04:
Unions zit in de stable, maakt niet uit hoe lang het erin zit, dat niet iedereen upgrade ligt niet aan de mensen die aan mysql werken

Hoeveel mensen van de apache 1.3.x serie zijn ondertussen op 2.0.x overgestapt?
En voor de genen die nog niet overgestapt zijn, wat zijn oa de redenen waarom ze niet overgestapt zijn?

Eentje die ik ken is iig dat de php-module nog steeds geen stabiele support voor apache 2.0.x kent.
Andere redenen om niet over te stappen op een onbewezen nieuwe stable is gewoon het standaard 'kat uit de boom kijken'. Ik kan me heel goed voorstellen dat je nog niet wil overstappen op de nieuwste stable release, zeker omdat het een major versie upgrade is.

De ergste vindt ik persoonlijk
2. SELECT 'A' = 'a' levert true op.

Dat is idd ook de reden dat ik dat gedrag ken

Voor de rest een hele hoop punten die er idd wel mogen zijn. Maar dit zijn ook niet meteen de doelstellingen van MySQL.

MySQL lijkt zich steeds meer te proberen te profileren als een "concurrent voor Oracle" (als je tenminste kijkt naar de nieuwsitems op hun eigen site enzo) en als ze dat enigszins serieus willen zijn, zullen ze dit soort rare gedragingen toch niet moeten hebben
Ik ben me overigens ter dege van bewust dat Oracle, Postgresql etc ook wel rare dingen doen

Wat is trouwens "de magie" rond MySQL? het is maar een RDBMS ... moest het nu een mooie sprookjes prinses zijn ok

Ik heb een beetje het idee dat er mensen zijn die denken dat ALLES wat in een DB kan in MySQL kan, of wellicht is het andersom. Dat mensen denken dat ALLES wat door een database gedaan kan worden, dat dat de functionaliteit is die MySQL biedt. Dus alles wat het mist, dat je dat ook niet nodig hebt. Of alleen in heel uitzonderlijke gevallen.

Een paar gemissen zijn eigenlijk ronduit hinderlijk of je zou er in een goede applicatie uitgebreid rekening mee moeten houden en/of omheen moeten programmeren (mooi voorbeeld is natuurlijk de mensen die in hun applicatie "transactie's" bouwen, voor de MyISAM tabellen).

[siggy]

Eum ik heb tenminste zo dat wanneer ik een sql statement in vbscript wil uitvoeren dat ik een int kolom in mysql kan aanspreken met 0 en met '0' wat ik dus vrij vreemd vind aangezien '' een string aanduit. (zal wel weer aan mij liggen)

[ACM]

Dat wijkt idd van de specs af (DB2 weigert dat bij mijn weten) maar is een veel voorkomend gedrag wat ik niet afkeur, er wordt gewoon een automatische conversie gedaan.

Maar anderzijds, het is niet aan de database te bepalen wat je probeerde in te voeren en in dat opzicht heb je gelijk dat een integer-veld altijd als 0 enzo gepresenteerd moet worden en niet als '0'

[Verwijderd]

Het sorteer probleem is mijn inziens helemaal geen probleem, maar gewoon een stukje slecht uitdenken van je database. Een varchar-veld word gewoon logisch op alfabet gesorteerd, net als bijvoorbeeld een text-veld. Wanneer je int-velden gaat sorteren sorteerd mysql dit chronologisch. Hetzelfde probleem als iemand aangeeft met 'Mijn datums sorteren niet goed chronologisch'. En later blijkt dat diegene de datums opslaat als dd-mm-jjjj in een kolom met type text.

[ACM]

Ow maar dat is het probleem ook niet...
Dat mysql accepteert een auto_increment op varchar's te leggen is wmb fout.

[Verwijderd]

Misschien kun je deze toevoegen

[alienfruit]

code:

7. Geen stored procedures/functions.

uuh. wat is er mis met stored procedures heeft mysql wel hoor.. je moet ze alleen in c schrijven, maar jah! Ze zijn er wel

[ACM]

Dat ie geen aliassen mee kan nemen? Humm.
Kan postgres ook niet En opzich is het niet zo gek dat ze dat niet kunnen, want het is tenslotte een veld dat uit de resultsets wordt samengesteld, nadat de filtering plaatsgevonden heeft.
* ACM zal es op de postgres mailinglist vragen waarom het daar niet kan.

En dat puntje van Annie zal ik sowieso nog even toevoegen iig.

[ACM]

alienfruit schreef op 29 March 2003 @ 16:47:

code:

7. Geen stored procedures/functions.

uuh. wat is er mis met stored procedures heeft mysql wel hoor.. je moet ze alleen in c schrijven, maar jah! Ze zijn er wel

Nee ze zijn er niet.
Je moet er je mysql voor recompilen en dat noem ik toch echt geen stored procedures en die paar UDF-functies die je kan gebruiken zijn vreselijk beperkt bij mijn weten. Daarnaast zou het fijn zijn als gewone gebruikers ze kunnen schrijven en toevoegen

[ Voor 8% gewijzigd door ACM op 29-03-2003 16:56 ]

[alienfruit]

Ach Stored Procedures is niet zo moeilijk om er in te ketsen imho

[Apache]

ACM schreef op 29 March 2003 @ 16:18:

[...]

Hoeveel mensen van de apache 1.3.x serie zijn ondertussen op 2.0.x overgestapt?
En voor de genen die nog niet overgestapt zijn, wat zijn oa de redenen waarom ze niet overgestapt zijn?

Eentje die ik ken is iig dat de php-module nog steeds geen stabiele support voor apache 2.0.x kent.
Andere redenen om niet over te stappen op een onbewezen nieuwe stable is gewoon het standaard 'kat uit de boom kijken'. Ik kan me heel goed voorstellen dat je nog niet wil overstappen op de nieuwste stable release, zeker omdat het een major versie upgrade is.

Een hele hoop mods waren/zijn nog steeds niet compatible met Apache (eis was dat alles threadsafe was), PHP moest hiervoor ook threadsafe libs gebruiken enz, het leek net een dominorij

MySQL heeft dit zeker niet zo hard, ik draai MySQL 4.0 sinds 4.0.1 en nooit stabiliteitsproblemen gehad of incompatibiliteit, php en andere dingen compileden er mooi tegen. En nooit SQL gehad die niet werkte. Dus de overgang van Apache 1 -> 2 was net wat incompatibeler dan nu.

Dat is idd ook de reden dat ik dat gedrag ken

Wat meteen door m'n hoofd flitste doen ik het wist was " "

MySQL lijkt zich steeds meer te proberen te profileren als een "concurrent voor Oracle" (als je tenminste kijkt naar de nieuwsitems op hun eigen site enzo) en als ze dat enigszins serieus willen zijn, zullen ze dit soort rare gedragingen toch niet moeten hebben
Ik ben me overigens ter dege van bewust dat Oracle, Postgresql etc ook wel rare dingen doen

Klopt maar op je eigen website gaan zetten van: "onze db ondersteund de helft niet maar dat kwakken we er later wel eens bij", dit doet geen enkel bedrijf.

K'bedoel kijk naar de grootste software firma, hoe vaak gooien zij niet met woorden als: reliable, manageble, upgradeable, thrustworthy, en alle andere buzzwords waar achterlijke managers meteen geil van worden. K'heb ze nog nooit reclame zien maken met blue screens.

Ik heb een beetje het idee dat er mensen zijn die denken dat ALLES wat in een DB kan in MySQL kan, of wellicht is het andersom. Dat mensen denken dat ALLES wat door een database gedaan kan worden, dat dat de functionaliteit is die MySQL biedt. Dus alles wat het mist, dat je dat ook niet nodig hebt. Of alleen in heel uitzonderlijke gevallen.

Klopt, maar de misinformed maken vaak een groter deel uit dan omgekeerd.
Het beste wat je met deze mensen kan doen is hopen dat het hun hobby is, en blijft natuurlijk

Een paar gemissen zijn eigenlijk ronduit hinderlijk of je zou er in een goede applicatie uitgebreid rekening mee moeten houden en/of omheen moeten programmeren (mooi voorbeeld is natuurlijk de mensen die in hun applicatie "transactie's" bouwen, voor de MyISAM tabellen).

[/quote]

Klopt. Mischien kan hier wel een opensource project uit groeien, "the MySQL supplemental library" ofzo

[ACM]

Apache schreef op 29 March 2003 @ 17:33:
MySQL heeft dit zeker niet zo hard, ik draai MySQL 4.0 sinds 4.0.1 en nooit stabiliteitsproblemen gehad of incompatibiliteit, php en andere dingen compileden er mooi tegen. En nooit SQL gehad die niet werkte. Dus de overgang van Apache 1 -> 2 was net wat incompatibeler dan nu.

Daar heb je natuurlijk wel weer gelijk in, maar punt blijft natuurlijk staan dat men altijd voor een productie server de kat uit de boom kijkt. Hoe lang ze dat doen hangt van het vertrouwen van de beheerder, de applicatie en de noodzaak up te graden vanwege nieuwe functionaliteit.

Wat meteen door m'n hoofd flitste doen ik het wist was " "

Bekend gevoel

Klopt maar op je eigen website gaan zetten van: "onze db ondersteund de helft niet maar dat kwakken we er later wel eens bij", dit doet geen enkel bedrijf.

Yups, maar dat is dus een beetje wat ik met de 'magie' bedoel, wellicht was 'mythes' een beter woord

Klopt. Mischien kan hier wel een opensource project uit groeien, "the MySQL supplemental library" ofzo

Die is er toch al? Die heet postgresql

Anyway, opzich zou het wel handig zijn als mysql voornamelijk de "simpele, snelle, geordende opslag" wordt/blijft en bijvoorbeeld postgresql de "geavanceerde, correcte opslag" blijft/wordt.
Ze groeien enorm naar elkaar toe, maar de belangrijkste drijfveer voor bepaalde beslissingen bij MySQL lijkt 'performance' te zijn (overal waar iets staat wat anders is wordt er de performance bijgehaald, lijkt het) en bij PostgreSQL de 'correctheid'.

Toevallig was dat onderwerp nog op de postgres-mailling list. De conclusie van iemand die een vrij uitgebreide vergelijking van een aantal punten deed:

"The cornerstone of MySQL is performance above all, the cornerstone of
Postgresql is correctness above all."

[Just_a_Gamer]

Iets in de trant van XML support ==> Zoiets als XSQL Servlet bij oracle en XML Support bij MS sql server 2000 mis ik bij MySQL

[jochemd]

5. Case-sensitive tabelnamen.

Tabelnamen horen in sommige gevallen wel en in andere gevallen niet case-sensitive te zijn
Volgens de SQL specificatie moeten alle identifiers (namen van kolommen, functies, tabellen etc.) in een query eerst UPPERCASE gemaakt worden, en dan moeten ze exact gematched worden met de bestaande identifiers. Maar aangezien die bestaande identifiers ook ooit de zelfde procedure zijn doorlopen is dat geen probleem.
Uitzondering zijn die identifiers die door identifier quotes worden geidentificeerd (double quotes). Daarvan mag de case niet aangepast worden. Volgens de standaard betekent dat:

code:

CREATE TABLE  test  (); SELECT * FROM  test   ---> werkt
CREATE TABLE  TEst  (); SELECT * FROM "TEST"  ---> werkt
CREATE TABLE  TEst  (); SELECT * FROM "test"  ---> werkt niet
CREATE TABLE  test  (); SELECT * FROM "test"  ---> werkt niet
CREATE TABLE "TEST" (); SELECT * FROM  test   ---> werkt
CREATE TABLE "TesT" (); SELECT * FROM "TesT"  ---> werkt

Ik zou het trouwens helemaal niet erg vinden als je die lijst in het Engels maakte.

PS ACM, je kan de SQL standaard gewoon downloaden uit de TU bibliotheek. Het is ISO 9075, bereikbaar via de NEN normenshop.

[jochemd]

Bug:
Bij een insert in een numeriek veld wordt '' (zero byte string) geconverteerd naar 0.

Gemis:
Boolean datatype
Interval datatype
Support voor AT TIME ZONE 'EST'. Of moeten we daar maar gewoon timezones in zijn algemeen van maken?

[alienfruit]

Kun je niet het datatype BIT gebruiken voor boolean? Dat is toch ook uit/aan

[ACM]

alienfruit schreef op 29 maart 2003 @ 18:05:
Kun je niet het datatype BIT gebruiken voor boolean? Dat is toch ook uit/aan

TINYINT[(M)] [UNSIGNED] [ZEROFILL]
A very small integer. The signed range is -128 to 127. The unsigned range is 0 to 255.
BIT
BOOL
These are synonyms for TINYINT(1).

en zie mijn eerdere klacht over Int(10) == Int(1), in die tinyint(1) kan je bij mijn weten gewoon 100 opslaan...

[chem]

Wat random ergernissen:
[list]
• ORDER BY ... DESC sorteren levert een filesort op
• EXPLAIN is niet nauwkeurig
• 1 varchar bij een char table, alle kolommen worden varchar, is niet eenvoudig vv allemaal naar char te krijgen

[JaQ]

Ik ontdekte vrij recent dat het mogelijk is om foreign keys aan te maken in MySQL. Best grappig, aangezien je dan je referenciele integriteit kan afdwingen. Alleen wel jamer dat MySQL vervolgens deze foreign keys niet controleerd by het uitvoeren van een insert of update is dan toch wel weer bijzonder. (maar volgens mij was dat in 4.0.1) (hoezo Rdbms, meer dbms dus)

Transactiesupport mis ik dagelijks in MySQL. In versie 4 zou dit ondersteund moeten worden (alleen wel jammer dat de performance meteen 0 is)

Ik snap overigens je irritatie over het feit dat MySQL alle char velden omzet in varchar (bij meer dan 4 karakters), maar er is wel een goede reden voor (namelijk lokaal diskgebruik. Als je namelijk 2 karakters in een char(300) veld zou zetten, dan wordt op fs niveau toch de ruimte gepakt voor 300 karakters. En eigenlijk wil je dat niet)

Persoonlijk vind ik MySQL voor selectie van gegevens een van de betere opties om te gebruiken. (mits er niet te veel data in zit). m.i. is de snelheid bij selectie de grootste USP van MySQL. Dat zou ook zo moeten blijven (zie cornerstone). betekend helaas wel dat je bepaalde functionaliteit gaat missen...

Just my 2 cts.

[ACM]

jochemd schreef op 29 March 2003 @ 18:00:
Ik zou het trouwens helemaal niet erg vinden als je die lijst in het Engels maakte.

Is idd een idee
Bedankt voor die extra uitleg trouwens.

PS ACM, je kan de SQL standaard gewoon downloaden uit de TU bibliotheek. Het is ISO 9075, bereikbaar via de NEN normenshop.

Idd es doen

jochemd schreef op 29 March 2003 @ 18:03:
Bug:
Bij een insert in een numeriek veld wordt '' (zero byte string) geconverteerd naar 0.

Gemis:
Boolean datatype
Interval datatype
Support voor AT TIME ZONE 'EST'. Of moeten we daar maar gewoon timezones in zijn algemeen van maken?

Timezone had ik eigenlijk al met 'locale support' gepakt, maar zal dat er idd expliciet bij melden

chem schreef op 29 March 2003 @ 18:12:
Wat random ergernissen:
[list]
• ORDER BY ... DESC sorteren levert een filesort op
• EXPLAIN is niet nauwkeurig
• 1 varchar bij een char table, alle kolommen worden varchar, is niet eenvoudig vv allemaal naar char te krijgen

Owja, zinloze explain. Sorteren staat er al bij

[ACM]

DrFrankenstoner schreef op 29 March 2003 @ 18:13:
Ik ontdekte vrij recent dat het mogelijk is om foreign keys aan te maken in MySQL. Best grappig, aangezien je dan je referenciele integriteit kan afdwingen. Alleen wel jamer dat MySQL vervolgens deze foreign keys niet controleerd by het uitvoeren van een insert of update is dan toch wel weer bijzonder. (maar volgens mij was dat in 4.0.1) (hoezo Rdbms, meer dbms dus)

Ik hoop dat het dit ondertussen wel doet dan

Ik snap overigens je irritatie over het feit dat MySQL alle char velden omzet in varchar (bij meer dan 4 karakters), maar er is wel een goede reden voor (namelijk lokaal diskgebruik. Als je namelijk 2 karakters in een char(300) veld zou zetten, dan wordt op fs niveau toch de ruimte gepakt voor 300 karakters. En eigenlijk wil je dat niet)

Ik weet dat dat de reden is
Maar als een database-designer voor een char(XX) kiest zou ie dat met een doordachte reden moeten doen, bijvoorbeeld omdat het veld altijd XX lang is. En dan geldt dat argument voor diskspace niet, want een char(XX) neemt minder ruimte in dan een varchar(XX) als ze beide volzitten

[TheDane]

with all due respect, ik vind dit toch _eigenlijk stiekem wel een beeeeeetje een non-topic.

vergelijk:

Topic: Een poging de magie rond MySQL te verwijderen

met:

Topic: Een poging de magie rond de Suzuki Alto te verwijderen

't merendeel van de op-/aanmerkingen is zeer terecht, daar niet van, maar al 't zogenaamde 'gemis', de 'bugs', de 'rare features' zijn allemaal in vergelijking met andere DB's. En zo heeft iedere prijsklasse z'n eigen voor- en nadelen.

Een Mercedes van €100k heeft veel meer extra's dan zo'n Suzuki'tje. Maar da's logisch, voor een Suzuki betaal je 8 keer zo weinig.

argh, terwijl ik deze post typ zie ik je signature ACM
lol


naja, point taken dan denk ik

[ACM]

PostgreSQL, Firebird, SapDB zijn ook gratis en zo zijn er wel meer

De meeste punten die ik ingevoerd heb zijn trouwens stiekem meer 'vs Postgres' dan 'vs de andere bekende databases', hoewel die laatste dan ook wel opgaat. Aangezien de meeste commerciele databases een superset van Postgresql's en MySQL's functionaliteit aanbieden op veel vlakken.
En Postgresql en Mysql zijn toch echt even 'duur'

[ACM]

En vertaald naar het engels

[Apache]

ACM schreef op 29 March 2003 @ 18:58:
PostgreSQL, Firebird, SapDB zijn ook gratis en zo zijn er wel meer

De meeste punten die ik ingevoerd heb zijn trouwens stiekem meer 'vs Postgres' dan 'vs de andere bekende databases', hoewel die laatste dan ook wel opgaat. Aangezien de meeste commerciele databases een superset van Postgresql's en MySQL's functionaliteit aanbieden op veel vlakken.
En Postgresql en Mysql zijn toch echt even 'duur'

Duur in aanschaf, aangezien Postgresql veeeel meer ondersteund dan Mysql zal je persoonlijk een langere training moeten doorlopen en is Mysql goedkoper?

[ACM]

Verwijderd schreef op 29 maart 2003 @ 16:46:
Misschien kun je deze toevoegen

Arjen van der Meijden <acm at tweakers.net> writes:
> I know it isn't possible to do queries like:
> SELECT 1 AS c, c + 1 AS d;

> But is there a good reason not to support it or is it something like
> "not yet implemented", "not interesting" or "to complex to (easily)
> implement".

It's not supported because it would violate the SQL spec. The spec is perfectly clear about the scope of names, and a SELECT's output column names aren't in scope anywhere in the SELECT itself (except in ORDER BY). If we treated them as if they were, we'd break queries that rely on the spec-mandated scoping --- think about cases where the output column names happen to conflict with column names available from the input tables.

You can however use a sub-select:
SELECT * FROM
(SELECT intfield AS a, intfield * intfield AS square FROM tableX) AS ss WHERE a < 10 AND square < 50

Note that it'd be unwise to assume this technique will eliminate double evaluations of expressions. But it saves having to type them more than once, at least.

regards, tom lane

Tom Lane is een van de belangrijkste devvers aan Postgresql's core.

Just_a_Gamer schreef op 29 maart 2003 @ 17:59:
Iets in de trant van XML support ==> Zoiets als XSQL Servlet bij oracle en XML Support bij MS sql server 2000 mis ik bij MySQL

Op dit soort punten wordt het verschil tussen gratis en dure commerciele punten zichtbaar, mysql heeft ook geen l33te GUI-frontend voor het beheer van alle opties etc etc.
Lijkt me een beetje flauw om dat er ook nog eens bij te gaan trekken, hoewel het zeker af en toe een gemis zal zijn

[jochemd]

Apache schreef op 30 March 2003 @ 12:38:

Duur in aanschaf, aangezien Postgresql veeeel meer ondersteund dan Mysql zal je persoonlijk een langere training moeten doorlopen en is Mysql goedkoper?

Het simpele feit dat PostgreSQL veel meer ondersteunt dan MySQL betekent niet dat je al die features moet gebruiken als je niet weet hoe het moet. En voor de mensen die wel weten hoe dat moet scheelt het juist gigantisch veel tijd omdat ze niet op zoek moeten naar workarounds voor niet geimplementeerde features.

[Slagroom]

Dit zijn misschien allemaar redenen om een nieuwe (R)DBMS te beginnen... ik heb al een naam voor de project groep...

FAMSQL -> Front Anti MySQL

[whoami]

jochemd schreef op 30 March 2003 @ 14:20:
[...]

Het simpele feit dat PostgreSQL veel meer ondersteunt dan MySQL betekent niet dat je al die features moet gebruiken als je niet weet hoe het moet. En voor de mensen die wel weten hoe dat moet scheelt het juist gigantisch veel tijd omdat ze niet op zoek moeten naar workarounds voor niet geimplementeerde features.

Dingen zoals referential integrity, transactions ed zijn toch wel dingen die noodzakelijk zijn voor een relational database-system.
Foreign keys en referentiele integriteit zijn dingen die een RDBMS moet bezitten, en die je echt nodig hebt als je een serieuze applicatie bouwt.
Hetzelfde geldt trouwens voor transacties.
Deze voorbeelden noem ik trouwens geen 'features', maar 'noodzakelijkheden'.

Slagroom schreef op 30 maart 2003 @ 15:03:
Dit zijn misschien allemaar redenen om een nieuwe (R)DBMS te beginnen... ik heb al een naam voor de project groep...

FAMSQL -> Front Anti MySQL

Voorlopig zijn er genoeg alternatieven op de markt hoor.
who needs Yet Another RDBMS ?

[ Voor 23% gewijzigd door whoami op 30-03-2003 22:08 ]

[Slagroom]

whoami schreef op 30 March 2003 @ 22:06:

[...]


Dingen zoals referential integrity, transactions ed zijn toch wel dingen die noodzakelijk zijn voor een relational database-system.
Foreign keys en referentiele integriteit zijn dingen die een RDBMS moet bezitten, en die je echt nodig hebt als je een serieuze applicatie bouwt.
Hetzelfde geldt trouwens voor transacties.
Deze voorbeelden noem ik trouwens geen 'features', maar 'noodzakelijkheden'.


[...]


Voorlopig zijn er genoeg alternatieven op de markt hoor.
who needs Yet Another RDBMS ?

Ook een naam voor een RDBMS -> YARDBMS

[MAZZA]

jochemd schreef op 30 March 2003 @ 14:20:
[...]

Het simpele feit dat PostgreSQL veel meer ondersteunt dan MySQL betekent niet dat je al die features moet gebruiken als je niet weet hoe het moet. En voor de mensen die wel weten hoe dat moet scheelt het juist gigantisch veel tijd omdat ze niet op zoek moeten naar workarounds voor niet geimplementeerde features.

Dit klinkt als een 800PK sterke motor op een woonerf. Als je die extra features niet gebruikt dan neem je een 'simpelere' motor.

Daarom vind ik een vergelijk tussen PostgreSQL en MySQL een beetje krom. Het feit dat ze beiden gratis zijn maakt het nog niet mogelijk om beiden te vergelijken met elkaar. Als je features mist in vergelijking met PostgreSQL dan gebruik je toch PostgreSQL?

[ACM]

MAZZA schreef op 31 maart 2003 @ 09:31:
Dit klinkt als een 800PK sterke motor op een woonerf. Als je die extra features niet gebruikt dan neem je een 'simpelere' motor.

Totdat je op de snelweg wilt gaan rijden, met diezelfde motor...

Daarom vind ik een vergelijk tussen PostgreSQL en MySQL een beetje krom. Het feit dat ze beiden gratis zijn maakt het nog niet mogelijk om beiden te vergelijken met elkaar. Als je features mist in vergelijking met PostgreSQL dan gebruik je toch PostgreSQL?

Kortom MySQL en PostgreSQL zijn ineens niet meer te vergelijken?
Dus MySQL is nergens mee te vergelijken, want de commerciele databases waren er al niet mee te vergelijken omdat ze geld kosten??

Persoonlijk vindt ik MySQL en PostgreSQL juist te vergelijken. Mede doordat ze beide gratis zijn en je dus bij beide geen overdaad aan 'grafische kerst' en 'dure features' hoeft te verwachten.

En het idee van dit topic is, min of meer, mensen ervan bewust te maken dat ze features (kunnen/zullen) missen

[ Voor 7% gewijzigd door ACM op 31-03-2003 09:52 ]

[Janoz]

MAZZA schreef op 31 March 2003 @ 09:31:
[...]

Dit klinkt als een 800PK sterke motor op een woonerf. Als je die extra features niet gebruikt dan neem je een 'simpelere' motor.

Daarom vind ik een vergelijk tussen PostgreSQL en MySQL een beetje krom. Het feit dat ze beiden gratis zijn maakt het nog niet mogelijk om beiden te vergelijken met elkaar. Als je features mist in vergelijking met PostgreSQL dan gebruik je toch PostgreSQL?

Waarmee mogen we MySQL dan vergelijken? Flat file? Met wc, grep, find, more, cat en sort heb je ongeveer dezelfde functionaliteit. Je mist alleen de sql frontend. Of is dat ook weer flauw?

[ Voor 1% gewijzigd door Janoz op 31-03-2003 09:59 . Reden: Nog wat functionaliteiten van flatfile toegevoegd. ]

[Yo-han]

Mmm, ok.... In de week van 19 mei zit ik bij de eerste MySQL Training in Nederland. (ze heben nu ook een nederlandse partner en das weer een klant van ons...)

Als ACM zijn lijstje klaar heeft moet ie die maar ff mailen dan zal ik alles is even haarfijn uit gaan zoeken bij die mannen en ze om redelijke feedback vragen...

[ACM]

Bovenstaande url blijft gewoon beschikbaar hoor

[Verwijderd]

MAZZA schreef op 31 maart 2003 @ 09:31:
[...]

Dit klinkt als een 800PK sterke motor op een woonerf. Als je die extra features niet gebruikt dan neem je een 'simpelere' motor.

Daarom vind ik een vergelijk tussen PostgreSQL en MySQL een beetje krom. Het feit dat ze beiden gratis zijn maakt het nog niet mogelijk om beiden te vergelijken met elkaar. Als je features mist in vergelijking met PostgreSQL dan gebruik je toch PostgreSQL?

Het feit blijft dat MySql, het trabantje, zich wil vergelijken met met Oracle, de Rolls Royce.

[EfBe]

Humor, deze posting:

Arjen van der Meijden <acm at tweakers.net> writes:
> I know it isn't possible to do queries like:
> SELECT 1 AS c, c + 1 AS d;

> But is there a good reason not to support it or is it something like
> "not yet implemented", "not interesting" or "to complex to (easily)
> implement".

It's not supported because it would violate the SQL spec. The spec is perfectly clear about the scope of names, and a SELECT's output column names aren't in scope anywhere in the SELECT itself (except in ORDER BY). If we treated them as if they were, we'd break queries that rely on the spec-mandated scoping --- think about cases where the output column names happen to conflict with column names available from the input tables.

Nou, deze 'Tom' mag dan wel spreken over een SQL spec, maar daar zijn er nogal wat van. Welke bedoelt hij, Sql-92, sql99, Sql200x ? En bedoelt hij dan ook de Oracle Interpretatie, de IBM interpretatie of de MS interpretatie ervan? Dus 'would voilate the Sql spec' is dan imho wat overdreven, omdat er geen consensus over is en waarschijnlijk nooit komt ook. Joe Celko, mr Sql himself en ex-iso boardmember voor de SQL standaard, heeft ooit eens gezegd "The SQL Standard is going nowhere" en dat was na de Sql92 standaard. Tot op de dag van vandaag is dat bewaarheid en lijken geen van de grote database spelers die Sql ondersteunen ook maar een klein beetje toe te geven en de standaard volledig te adopteren. De definities van de standaarden zijn overigens alleen tegen dikke betaling aan ISO te bemachtigen. (en ik begrijp btw niet waarom aliasses van outputcolumns niet in de where clauses kunnen worden gebruikt, ook in sqlserver niet. )

[jochemd]

EfBe schreef op 31 maart 2003 @ 15:40:
Humor, deze posting:

Nou, deze 'Tom' mag dan wel spreken over een SQL spec, maar daar zijn er nogal wat van. Welke bedoelt hij, Sql-92, sql99, Sql200x ?

Gemiddeld genomen 92, hij vermeldt het expliciet als het 99 is.

En bedoelt hij dan ook de Oracle Interpretatie, de IBM interpretatie of de MS interpretatie ervan?

Er is over dit deel van de spec volgens mij geen debat.

Tot op de dag van vandaag is dat bewaarheid en lijken geen van de grote database spelers die Sql ondersteunen ook maar een klein beetje toe te geven en de standaard volledig te adopteren.

Het gaat langzaam, maar als je bijvoorbeeld kijkt naar wat Oracle heeft gedaan bij de stap van 8 naar 9 dan zie je dat ze met veel dingen toch wel heel veel verder compliant zijn geworden.

De definities van de standaarden zijn overigens alleen tegen dikke betaling aan ISO te bemachtigen.

Nee hoor. Ga gewoon bij de nationale technische bibliotheek langs (i.e. de bibliotheek van de TU Delft) en download een exemplaar c.q. trek het van de plank (ze hebben zelfs de papieren versie). Als je de weg weet op de websites van de juiste standaardenorganisaties staan ze daar ook op (maar ik ga niet posten waar, want als iedereen ze massaal gaat downloaden dan zijn ze daar ook zo weg).

(en ik begrijp btw niet waarom aliasses van outputcolumns niet in de where clauses kunnen worden gebruikt, ook in sqlserver niet. )

Omdat er dan een verschillende interpretatie kunnen bestaat van de volgende query:

code:

SELECT a AS b, b AS a
FROM c
WHERE a = 1

[ACM]

Ik gok dat ie het over de meest recente heeft en anders sql99.
De kans is aanwezig dat de definitie van die scope niet veranderd is sinds slq92 en in dat geval heeft ie het over alledrie. Aangezien MS dit hetzelfde uitvoert als Postgres zal ie op zijn minst de interpretatie daarvan bedoelen, maar ik gok dat de developers van Postgres recht hebben op een eigen visie op van diezelfde specs. Net zo goed als IBM, Oracle en MS dat hebben

Men probeert iig Postgresql te laten conformeren aan de meest recente versie van de SQL-spec.

edit:

jochemd is sneller en vollediger

[ Voor 5% gewijzigd door ACM op 31-03-2003 16:19 ]

[xoror]

Wat dat betreft 'enhancen' alle db's wel wat

Niet elke db is perfect, je moet leren leven met evt tekortkomingen. (al mag wel worden vermeld dat mysql er een boel heeft). ik werk dagelijks met mysql en pgsql en ik vind ze prima voor hun doeleinden.

Ik zie veel goede reacties over postgresql. Op zich ben ik hier ook voorstander van. Alleen vind ik wel dat deze ook een paar eigenaardigheden heeft (maar ik kan er prima mee leven).

de eigenaardigheden zijn:
1. indexen die niet gecleaned worden bij een vacuum (ook niet met full).
enige oplossing is complete dump/restore of wat eenvoudiger reindex gebruiken.
dit probleem krijg je bij tabellen waar data veel verandert en er ook indices op bepaalde
kolommnen zijn gedefinieerd. nadeel is dat je tijdelijk je index die gereindexed wordt niet kan gebruiken.

2. Vacuum analyze claimt geen hdd ruimte terug. Op zich geen probleem, maar je moet een vacuum full gebruiken die nog steeds de tabellen locked. Je gaat problemen hiermee krijgen als je 24 h db heb die veel turnover van de data heeft (maw, veel veranderingen in records, door modify, inserts, deletes). Een vacuum full kan vrij lang duren als je heel veel data heb (met veel veranderingen etc).

voor de rest is het een prima db waar ik met plezier mijn producten op ontwikkel.

[EfBe]

Jochemd: ik heb lang gezocht naar een pdf met de sql-99 of sql-92 standaard. Voor mn generator moest ik sql in OO modelen zeg maar, en wilde dat doen door de standaard te modellen. Ik kon echter die niet vinden, wel ergens een dir met weet ik hoeveel pdfs van tig mb groot met cryptische namen en geen uitleg, ik heb het op een gegeven moment maar opgegeven en heb oracle + sqlserver genomen. Bedankt iig voor je uitleg

die query overigens zou geen ambiguiteit hoeven te bevatten als je stelt dat aliasses columnnames overrulen. Die where zou dan gewoon dus b=1 doen. Je zou ook een alias naar een bestaande columname kunnen verbieden syntactisch.

Over prutsdatabases gesproken, ik zit net een access db-tje te converteren naar SqlServer, en die broddelaar die die accessdb heeft gebakken vond het niet nodig om bij keys alle properties goed te zetten. Door deze nalatigheid zag ik iets briljants: een PK field die niet required is . Dus ACM, het kan erger dan MySQL

[ACM]

EfBe schreef op 31 March 2003 @ 16:39:
en die broddelaar die die accessdb heeft gebakken vond het niet nodig om bij keys alle properties goed te zetten. Door deze nalatigheid zag ik iets briljants: een PK field die niet required is . Dus ACM, het kan erger dan MySQL

Wow

Dat lukt zelfs MySQL niet
_{Hoewel ik dat wel voor de zekerheid even getest had}

[ Voor 9% gewijzigd door ACM op 31-03-2003 16:46 ]

[jochemd]

EfBe schreef op 31 maart 2003 @ 16:39:

die query overigens zou geen ambiguiteit hoeven te bevatten als je stelt dat aliasses columnnames overrulen. Die where zou dan gewoon dus b=1 doen. Je zou ook een alias naar een bestaande columname kunnen verbieden syntactisch.

Beiden zijn niet gewenst omdat die een backward compatibility probleem opleveren
Het enige wat ik me als een goede oplossing zou kunnen voorstellen is dat je het toestaat maar definieert dat columnnamen (en andere identifiers!) aliassen overrulen.

[Verwijderd]

MySQL is een beperkt DBMS, wat idd vooral met simpele queries op simpele tables indrukwekkende performance kan leveren, maar na het uitbreiden van de complexiteit al redelijk snel de weg kwijt raakt. Daar valt mee te leven, zolang je de grenzen maar weet.

Wat ik storender vind is de grote groep mensen die die grenzen duidelijk niet weten of zien, waarschijnlijk omdat ze nog nooit een complexe query gezien of geschreven hebben, en MySQL de hemel in prijzen als de alleskunner. Inmiddels is MySQL ook bij managers bekender geworden, die dan op aanraden van de buurman die "verstand heeft van computers" met een gerust hart voorstellen om een complex Oracle domain even naar MySQL te porten... Want dat is veel beter

Wmb mag dus aan de lijst worden toegevoegd de grote groep mensen die geen echt DBMS of echte complexe queries kennen, maar wel prediken dat MySQL dit allemaal aankan

[marty]

Wat ik echt zwaar irritant aan MySQL vind is hoe het met GROUP BY en MAX omgaat
stel je heb de volgende tabel:

code:

CREATE TABLE maxgroep (
  id tinyint(3) unsigned NOT NULL auto_increment,
  leeftijd tinyint(3) unsigned default NULL,
  naam varchar(100) default NULL,
  groep tinyint(3) unsigned default NULL,
  PRIMARY KEY  (id)
) TYPE=MyISAM;

INSERT INTO maxgroep VALUES("1", "20", "Jan", "1");
INSERT INTO maxgroep VALUES("2", "19", "klaas", "2");
INSERT INTO maxgroep VALUES("3", "18", "piet", "3");
INSERT INTO maxgroep VALUES("4", "21", "joop", "1");
INSERT INTO maxgroep VALUES("5", "22", "karel", "2");
INSERT INTO maxgroep VALUES("6", "25", "hans", "3");

en je laat daar deze query op los:

code:

SELECT MAX(leeftijd) AS leeftijd, naam, groep
FROM maxgroep
GROUP BY groep
ORDER BY groep

Dan beweert mysql vervolgens dat

code:

leeftijd    naam    groep
21      Jan 1
22      klaas   2
25      piet    3

Wat het doet is groeperen op groep, daar de hoogste leeftijd uit pakken en vervolgens gewoon de eerst-ingevoerde waarde die het tegenkomt uit de naam-kolom, ipv de naam die bij de hoogste leeftijd hoort.
Ook niet helemaal volgens de standaard volgens mij....


btw, klein puntje:

3. MySQL will always try to insert a date into a date field, even if you supply a bogus string (it'll insert 0000-00-00 than).
4. MySQL will also insert 0 into a numeric field if you supply an empty or bogus string.

bij 4 noem je expliciet empty or bogus en bij 3 alleen bogus. maar ook daar gaat het verhaal voor empty op

edit:
Wat ik trouwens ook raar vind is dat een VARCHAR(1) veld net zoveel ruimte inneemt als VARCHAR(255). Je kunt dus netzogoed alles 255 maken.

[ Voor 15% gewijzigd door marty op 31-03-2003 18:38 ]

[ACM]

marty schreef op 31 March 2003 @ 18:32:
Wat het doet is groeperen op groep, daar de hoogste leeftijd uit pakken en vervolgens gewoon de eerst-ingevoerde waarde die het tegenkomt uit de naam-kolom, ipv de naam die bij de hoogste leeftijd hoort.
Ook niet helemaal volgens de standaard volgens mij....

Dat klopt geloof ik wel, enige nadeel is dat je daar de standaard workaround weer niet voor kan toepassen:
SELECT ... FROM tabel t WHERE leeftijd = (SELECT MAX(leeftijd) FROM tabel t2 WHERE t.groep = t2.groep);

bij 4 noem je expliciet empty or bogus en bij 3 alleen bogus. maar ook daar gaat het verhaal voor empty op

KLopt, even aanpassen

edit:
Wat ik trouwens ook raar vind is dat een VARCHAR(1) veld net zoveel ruimte inneemt als VARCHAR(255). Je kunt dus netzogoed alles 255 maken.

Je bedoelt daarmee dat een varchar van 20 chars net zo veel ruimte neemt in een varchar(20) als in een varchar(255) veld?

Want zover ik kan testen leveren twintig waarden in een varchar(255) veld wel wat meer data op dan twintig waarden in een varchar(20) veld, net getest iig.

[ Voor 21% gewijzigd door ACM op 31-03-2003 18:50 ]

[ACM]

Verwijderd schreef op 31 March 2003 @ 18:21:
Wmb mag dus aan de lijst worden toegevoegd de grote groep mensen die geen echt DBMS of echte complexe queries kennen, maar wel prediken dat MySQL dit allemaal aankan

Die mensen mag je direct op mijn lijst wijzen iig, het is geen bug/rarigheid/gemis van MySQL denk ik

[marty]

ACM schreef op 31 March 2003 @ 18:40:
[Dat klopt geloof ik wel, enige nadeel is dat je daar de standaard workaround weer niet voor kan toepassen:
SELECT ... FROM tabel t WHERE leeftijd = (SELECT MAX(leeftijd) FROM tabel t2 WHERE t.groep = t2.groep);

Eg waar? Hmm...dat ga ik toch even ergens nazoeken als je het niet erg vindt. Doet Postgre het dan ook zo? (dat ken ik namelijk niet)

Je bedoelt daarmee dat een varchar van 20 chars net zo veel ruimte neemt in een varchar(20) als in een varchar(255) veld?

Want zover ik kan testen leveren twintig waarden in een varchar(255) veld wel wat meer data op dan twintig waarden in een varchar(20) veld, net getest iig.

Typisch want dit staat op de mysql site:

code:

Column type Storage required  
CHAR(M)     M bytes, 1 <= M <= 255  
VARCHAR(M)  L+1 bytes, where L <= M and 1 <= M <= 255

For example, a VARCHAR(10) column can hold a string with a maximum length of 10 characters. The actual storage required is the length of the string (L), plus 1 byte to record the length of the string.

daaruit mag je volgens mij opmaken dat als je in een VARCHAR(10) veld bla invult, dat 4 bytes in beslag neemt, en dat als je het in een VARCHAR(255) veld in vult het nog steeds 4 bytes in beslag neemt. Oftewel...het maakt kein flaus aus en kun je 'm dus net zo goed altijd op 255 zetten

p.s. ik heb het zelf ook nog even getest (VARCHAR(10) vs VARCHAR(255) en ik krijg twee tabellen van exact dezelfde grootte. Let even op dat je ze niet perongeluk CHAR maakt, want daar maakt het wel bij uit.
maargoed, je zou kunnen denken: wat doet ie dan moeilijk, maar ik vind het in zoverre raar dat mysql wel van je eist dat je een grootte opgeeft voor een kolom van dit veldtype, terwijl het dus in feite weinig uitmaakt

[ Voor 16% gewijzigd door marty op 31-03-2003 19:53 ]

[ACM]

marty schreef op 31 March 2003 @ 19:46:
daaruit mag je volgens mij opmaken dat als je in een VARCHAR(10) veld bla invult, dat 4 bytes in beslag neemt, en dat als je het in een VARCHAR(255) veld in vult het nog steeds 4 bytes in beslag neemt. Oftewel...het maakt kein flaus aus en kun je 'm dus net zo goed altijd op 255 zetten

D0h, dat zeg ik net

Het verschil zit hem erin dat je soms strings wilt af kunnen op maximaal een bepaalde grootte. Dan is het leuk dat je database dat voor je doet (niet dat mysql dat dan afdwingt, die kapt het gewoon af en slaat het alsnog op )

[Annie]

2. SELECT 'A' = 'a' gets you true.

Vind dat persoonlijk niet zo'n probleem, het is pas erg als je het niet kan wijzigen (in MSSQL heet dat collation, weet zo niet of het een algemene term is).

ACM schreef op 29 March 2003 @ 16:18:
Daarnaast wijkt het bij mijn weten af van de SQL-specs en doen alle andere databases (die ik ken) netjes case-insensitive tabelnamen.

MSSQL kan ook case sensitive zijn als je dat wil. Objecten worden opgeslagen in systeemtabellen en als deze met een CS collation (deja-vu) zijn aangemaakt dan heb je wat je wil, maar ja, of je dat nou zo graag moet willen is een tweede

[ACM]

Annie schreef op 31 March 2003 @ 20:16:
Vind dat persoonlijk niet zo'n probleem, het is pas erg als je het niet kan wijzigen (in MSSQL heet dat collation, weet zo niet of het een algemene term is).

Je kan het wel aanpassen ('varchar(XX) binary' maken, binary als keyword meegeven bij de select oid, of strcmp() gebruiken) maar ik vind het vreemd gedrag, zeker dat het default is.

[jochemd]

marty schreef op 31 March 2003 @ 19:46:

Typisch want dit staat op de mysql site:

code:

Column type Storage required  
CHAR(M)     M bytes, 1 <= M <= 255  
VARCHAR(M)  L+1 bytes, where L <= M and 1 <= M <= 255

daaruit mag je volgens mij opmaken dat als je in een VARCHAR(10) veld bla invult, dat 4 bytes in beslag neemt, en dat als je het in een VARCHAR(255) veld in vult het nog steeds 4 bytes in beslag neemt.

Dat lees ik er ook in

Oftewel...het maakt kein flaus aus en kun je 'm dus net zo goed altijd op 255 zetten

Dat lees ik er niet in. Je zit namelijk vaak met andere limieten die je graag wil enforcen. Zo is het bijvoorbeeld zo dat volgens de officiële normen een adres in Nederland maar 43 karakters mag zijn, dus wil je nooit dat er een langere string in je database komt in het adres veld.

Wat ik er wel in lees is dat MySQL geen iota begrijpt van multibyte characters

[marty]

ACM schreef op 31 March 2003 @ 20:07:

[...]

D0h, dat zeg ik net

ehmmm met alle respect hoor, maar volgens mij zeg je wat anders:

ACM: Want zover ik kan testen leveren twintig waarden in een varchar(255) veld wel wat meer data op dan twintig waarden in een varchar(20) veld, net getest iig.

Jij beweert daar dat het wel een verschil in data (ik neem aan dat je het over KBs heb) veroorzaakt. En dat doet het dus niet. Of ben ik nou dyslektiez?

ACM schreef op 31 March 2003 @ 20:07:Het verschil zit hem erin dat je soms strings wilt af kunnen op maximaal een bepaalde grootte. Dan is het leuk dat je database dat voor je doet (niet dat mysql dat dan afdwingt, die kapt het gewoon af en slaat het alsnog op )

jochemd schreef op 31 March 2003 @ 20:57:
Dat lees ik er niet in. Je zit namelijk vaak met andere limieten die je graag wil enforcen. Zo is het bijvoorbeeld zo dat volgens de officiële normen een adres in Nederland maar 43 karakters mag zijn, dus wil je nooit dat er een langere string in je database komt in het adres veld.:'(

Dat heeft imho dus echt totaaaal geen nut. Wat schiet je er nu mee op als je bijvoorbeeld een postcode veld op 6 karatkers zet en iemand voert een spatie in tussen de letters en de cijfers? Heb je een postcode met maar 1 letter - lekker dwingend. Of je vraagt mensen een password te nemen dat niet langer dan 10 tekens is waarbij je het veld ook limiteert tot 10 karakters (we md-vijfen de boel even niet voor het gemak ). Dan vragen die zich later af waarom ze niet in kunnen loggen met het password: ikleesdatsoortdingennooit , omdat er in de database staat ikleesdats. Dit soort dingen zul je altijd al van te voren (php,asp,etc) moeten controleren, want ook als je het via de shell invoert krijg je geen foutmelding van MySQL. Dus totaal onzinnig om die beperking er op te zetten. Kun je beter de beperking er niet opzetten, maar alleen in je interface en mocht die buggy zijn, dan kun je in ierdergeval nog achterhalen wat er wel is ingevoerd, ipv dat je met een afgekapte string zit

[jochemd]

marty schreef op 31 maart 2003 @ 21:39:

Dat heeft imho dus echt totaaaal geen nut. Wat schiet je er nu mee op als je bijvoorbeeld een postcode veld op 6 karatkers zet en iemand voert een spatie in tussen de letters en de cijfers? Heb je een postcode met maar 1 letter - lekker dwingend.

Daar schiet je ook niets mee op, je moet dan ook afdwingen dat er geen spaties in zitten (daar loopt nu ook een ander topic over).

Dus totaal onzinnig om die beperking er op te zetten. Kun je beter de beperking er niet opzetten, maar alleen in je interface en mocht die buggy zijn, dan kun je in ierdergeval nog achterhalen wat er wel is ingevoerd, ipv dat je met een afgekapte string zit

Tenzij het doorgeven van een te lange string aan de systemen er achter een probleem oplevert. Een bekend verhaal is dat een niet nader aan te duiden universiteit door te lange adressen oproepkaarten voor de studentenraadsverkiezingen had waar het laatste teken van een huisnummer er af viel omdat het stuk van het adres er voor te lang was.
Maar dit valt dus onder punt 9 van de lijst van ACM.

[ACM]

marty schreef op 31 March 2003 @ 21:39:
Jij beweert daar dat het wel een verschil in data (ik neem aan dat je het over KBs heb) veroorzaakt. En dat doet het dus niet. Of ben ik nou dyslektiez?

Twintig volle varchar(20)'s kosten minder data dan twintig volle varchar(255)'s.

Jij claimde dat een varchar ongeacht de grootte altijd evenveel data inneemt... En ik begreep daar niet helemaal uit welke variant je bedoelde, maar heb ze dus beiden beantwoord (een varchar(20) gevuld met twintig chars is kleiner dan een varchar(255) met 255 chars en een varchar(20) met tien chars is, logischerwijs, net zo groot in opslag als een varchar(255) met tien chars).

Dat heeft imho dus echt totaaaal geen nut. Wat schiet je er nu mee op als je bijvoorbeeld een postcode veld op 6 karatkers zet en iemand voert een spatie in tussen de letters en de cijfers? Heb je een postcode met maar 1 letter - lekker dwingend. Of je vraagt mensen een password te nemen dat niet langer dan 10 tekens is waarbij je het veld ook limiteert tot 10 karakters (we md-vijfen de boel even niet voor het gemak ). Dan vragen die zich later af waarom ze niet in kunnen loggen met het password: ikleesdatsoortdingennooit , omdat er in de database staat ikleesdats. Dit soort dingen zul je altijd al van te voren (php,asp,etc) moeten controleren, want ook als je het via de shell invoert krijg je geen foutmelding van MySQL. Dus totaal onzinnig om die beperking er op te zetten. Kun je beter de beperking er niet opzetten, maar alleen in je interface en mocht die buggy zijn, dan kun je in ierdergeval nog achterhalen wat er wel is ingevoerd, ipv dat je met een afgekapte string zit

Right Dat mysql zo onhandig is geen waarschuwing te geven zegt nog niet dat je dan maar gelijk niet je model goed moet modeleren.

Want diezelfde opmerkingen van je gaan op als iemand een string van 256 chars invoert en niet snapt waarom het niet werkt... Maak je er dan een text-veld van?

Zoals je in dit topic kan zien:
[rml][ postgres] SQL-query postcode check[/rml]
Kan je in databases met geavanceerde check-constraints heel goed beperken en forceren tot een bepaald formaat zonder dat je in je client-code precies moet weten wat de data definitie is van de velden.
Als je stored procedures gebruikt voor het invoeren van de data zou je zelfs nog meer kunnen doen daarmee.

Maar dat MySQL weigert een error op te gooien bij een te lange string had ik ook al in mijn lijstje gezet

* ACM heeft het puntje 'no CHECK-constraints' toegevoegd

edit:

En _weer_ is jochemd sneller

[ Voor 4% gewijzigd door ACM op 31-03-2003 22:02 ]

[marty]

over die adressen: dat was er ook afgevallen als ze de boel hadden laten afkappen door mysql, dus zie nog steeds het voordeel niet.
waar het mij eigenljk om gaat is dat mysql eist dat je een grootte op moet geven voor het varchar veld terwijl het daar niets meer mee doet dan bruut afkappen. En dat heeft in geen enkele situatie voordelen. het heeft alleen één nadeel: verlies van informatie. Maw een VARCHAR veld zonder opgaaf van grootte zou net zo goed, zo niet beter werken.
maargoed, ik ben bang dat we in herhaling gaan vallen. dus ik laat het wat betreft de varchars hier maar bij.

[jochemd]

marty schreef op 31 maart 2003 @ 22:23:
over die adressen: dat was er ook afgevallen als ze de boel hadden laten afkappen door mysql, dus zie nog steeds het voordeel niet.

Nee, dan was de g van Balthasar van der Polweg er af gevallen.

waar het mij eigenljk om gaat is dat mysql eist dat je een grootte op moet geven voor het varchar veld terwijl het daar niets meer mee doet dan bruut afkappen. En dat heeft in geen enkele situatie voordelen.

Behalve in het geval van het genoemde voorbeeld.

Maar wat my betreft gaat puntje 9 van de eigenaardigheden in het lijstje van ACM naar de sectie met bugs.

[ACM]

idd, verplaatst. Samen met twee andere puntjes (null waarden in een not-null veld en under-/overflow)

[Spider.007]

Int(10) is the same as int(1) eventhough the manual sais differently.

Oh en komen deze punten uit een mySQL database?

[ACM]

Hoe bedoel je dat?
Dit zijn allemaal punten die oa uit mijn eigen ervaring met MySQL voortkomen.
Als ik een Int(1) definieer kan ik daar prima 10000000 in opslaan...

En wat is er mis met die zin? Die heb ik getikt, dus als er wat mis is lees ik er toch overheen

[whoami]

Ik vind het zowiezo vreemd dat je een grootte/lengte kan meegeven aan een int (of eender welk numeriek) veld.

ACM schreef op 31 maart 2003 @ 22:58:
Hoe bedoel je dat?

En wat is er mis met die zin? Die heb ik getikt, dus als er wat mis is lees ik er toch overheen

says ipv sais

sais is frans ( je sais, weet je wel )

[ Voor 59% gewijzigd door whoami op 31-03-2003 23:07 ]

[ACM]

whoami schreef op 31 maart 2003 @ 23:06:
Ik vind het zowiezo vreemd dat je een grootte/lengte kan meegeven aan een int (of eender welk numeriek) veld.

Voor decimal en/of numeric vindt ik dat niet zo gek, die zijn zelfs zo gedefinieerd

Maar verder is het wel raar ja.

says ipv sais

sais is frans ( je sais, weet je wel )

*kuch*

[creative8500]

code:

SELET * FROM table ORDER BY RAND()

geeft in een tabel met drie rows maar een volgorde, hoe vaak je de query ook uitvoert. Niet volledig random dus.

[Verwijderd]

creative8500 schreef op 31 March 2003 @ 23:25:

code:

SELET * FROM table ORDER BY RAND()

geeft in een tabel met drie rows maar een volgorde, hoe vaak je de query ook uitvoert. Niet volledig random dus.

Omdat RAND() voor iedere rij dezelfde waarde terug geeft. Heeft dus weinig met "random" of "niet random" te maken .

Als je een tabel met een integer identity kolom hebt, kun je dit getal ook als seed gebruiken voor de RAND() functie. Op deze manier zou het ook "random" moeten zijn.

(Ik weet niet of MySQL iets heeft als NEWID(), maar ook op die manier kun je doen wat je wil in MSSQL.)

[ Voor 33% gewijzigd door Verwijderd op 31-03-2003 23:57 ]

[Verwijderd]

ACM schreef op 31 March 2003 @ 18:42:

[...]

Die mensen mag je direct op mijn lijst wijzen iig, het is geen bug/rarigheid/gemis van MySQL denk ik

Gedaan! 1 slimmerd wilde weten welk programma ACM is

Zou het mogelijk zijn om de lijst te laten toevoegen aan deze link

[ACM]

Verwijderd schreef op 01 april 2003 @ 12:25:
Gedaan! 1 slimmerd wilde weten welk programma ACM is

Dat ze dan nog denken dat het om de ACM organisatie gaat ok...

Zou het mogelijk zijn om de lijst te laten toevoegen aan deze link

Wat denk je zelf?

[Slagroom]

creative8500 schreef op 31 maart 2003 @ 23:25:

code:

SELET * FROM table ORDER BY RAND()

geeft in een tabel met drie rows maar een volgorde, hoe vaak je de query ook uitvoert. Niet volledig random dus.

code:

SELECT * FROM table GROUP BY RAND()

Werkt wel...

[ACM]

't Is alleen niet iets waar de group by functionaliteit voor bedoeld is... Wat nou als er van de 10000 resultaten die je terugkrijgt er twee dezelfde random waarde kregen? Hoe moeten die dan gegroupeerd worden?

[Annie]

ACM schreef op 01 April 2003 @ 19:51:
't Is alleen niet iets waar de group by functionaliteit voor bedoeld is... Wat nou als er van de 10000 resultaten die je terugkrijgt er twee dezelfde random waarde kregen? Hoe moeten die dan gegroupeerd worden?

en natuurlijk punt 9

[Verwijderd]

meuktracker: MySQL 4.1.0 alpha

[whoami]

Verwijderd schreef op 10 April 2003 @ 15:53:
meuktracker: MySQL 4.1.0 alpha

Some new features include:
Subqueries:[/code]
SELECT * FROM t1 WHERE t1.a=(SELECT t2.b FROM t2);[/code]

Dit vind ik vreemd.
Normaal gezien zou dit niet mogen kunnen uitgevoerd worden, aangezien de subquery meerdere rijen zou kunnen returnen. Dat = - teken zou dus moeten vervangen worden door IN

[ThaDaNo]

Wat weer niet goed werkt, want ik heb het hier geprobeerd met IN en dan krijg ik een db error

[DeverauX]

Wat weer niet goed werkt, want ik heb het hier geprobeerd met IN en dan krijg ik een db error

Dan moet je toch helaas de fout bij jezelf zoeken want MySQL is toch echt wel in staat een query uit te voeren waar gebruik wordt gemaakt van IN

[ACM]

devraux schreef op 11 April 2003 @ 16:39:
Dan moet je toch helaas de fout bij jezelf zoeken want MySQL is toch echt wel in staat een query uit te voeren waar gebruik wordt gemaakt van IN

Mja, bij een feature in een alpha release kan je van alles verwachten. Maar tegen de tijd dat mysql 4.1 stabiel is zijn we vast wel weer dik een jaar verder.

[Verwijderd]

Wat ik jammer vind aan MySQL is, dat het zo heerlijk kan crashen zonder dat je een fout melding of iets in die trand krijgt. Ik ben op dit moment een site aan het verbouwen en zie vaak dat mijn db crasht door een query; dan mag ik gelijk mijn hele pc opnieuw installeren.

Het zou leuk zijn als eerst de complete query getest zou worden en dan een error zou verschijnen zonder dat alles hangt

[MisterData]

Gisteren had ik een dermate lange query dat MySQL de hele site ophing... Eerst had ik een top10-query aangeroepen met meerdere joins. Die duurde vreselijk lang hn heb ik gecanceld. Omdat de rest van de site ook connect met de DB werkte die helemaal niet meer. Herstarten van MySQL of het killen van de thread was de enige optie Ik heb dit al es eerder gehad, alleen toen liep MySQL vast omdat na een lange query de /tmp map vol zat (was maar 400MB op mijn server)

[pjonk]

Voor mijn bedrijf hebben wij een webhost met Shared unix MySQL/PHP website.
Alle MySQL errors worden afgevangen en ik krijg automatisch een mailtje als er een MySQL error optreedt.

Nu krijg ik regelmatig de errors:
- Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
- Lost connection to MySQL server during query

En die errors komen voor bij willekeurige queries die helemaal niet zwaar zijn.
Zou misschien komen doordat we shared hosting hebben en de load te zwaar wordt af en toe.

[whoami]

MisterData schreef op 12 April 2003 @ 08:24:
Gisteren had ik een dermate lange query dat MySQL de hele site ophing... Eerst had ik een top10-query aangeroepen met meerdere joins. Die duurde vreselijk lang hn heb ik gecanceld. Omdat de rest van de site ook connect met de DB werkte die helemaal niet meer. Herstarten van MySQL of het killen van de thread was de enige optie Ik heb dit al es eerder gehad, alleen toen liep MySQL vast omdat na een lange query de /tmp map vol zat (was maar 400MB op mijn server)

Dat heeft imho niet zozeer direct met MySQL te maken maar 't kan ook te maken hebben met de kwaliteit van je query of, over het feit of je wel de nodige indexen gemaakt hebt, en deze ook gebruikt werden door je query.

[ACM]

whoami: MySQL is erg slecht in het optimisen van complexere queries.

Waar postgresql nog een tweetal indices kan gebruiken met zoiets:
stel de tabel heeft indices op: (veld1, veld2 en veld3) en (veld1, veld2 en veld4)
select * from tabel
where
( tabel.veld1 = X and tabel.veld2 = Y and tabel.veld3 = Z)
OR
( tabel.veld1 = X and tabel.veld2 = Y and tabel.veld4 = W)

Daar doet mysql een select op een van de twee indices en prutst de rest van het tweede OR-deel erbij via dezelfde index... Postgresql (en dan vast de grotere RDBMS-en ook) doet daar netjes een union van twee or-delen, waarbij ie de delen van de best bijpassende index haalt. De tijd verhield zich daardoor 30 ms in postgres vs 360 ms in mysql oid.

En ga zo maar door

Owja, herschrijven naar:
select * from tabel
where
veld1= X and veld2 = Y and (veld3 = Z or veld4 = w)

is niet perse efficienter

JonkieXL schreef op 12 April 2003 @ 10:24:
- Lost connection to MySQL server during query

Die zie ik ook erg vaak ja, of 'server went away during query' oid... Ook lekker zinvol, dat laatste betekend niet perse dat ie gecrashed is ofzo, maar gewoon dat het te lang duurde...

[ Voor 21% gewijzigd door ACM op 12-04-2003 15:09 ]