MySQL 5: eindelijk zakelijke pretentie?

Het Zweedse MySQL AB heeft met MySQL 5.0.13 de laatste Release Candidate van editie 5 van de populaire open-sourcedatabase uitgebracht. Als er geen grote problemen meer worden gevonden zal in november de definitieve release van MySQL 5 plaatsvinden. De nieuwe versie bevat een aantal features die door de gebruikers van de gratis editie met gejuich zullen worden onthaald, maar die de databaseserver bovendien tot een serieuze speler op de commerciële markt moeten maken.

Voor de object-georiënteerde programmeurs is de implementatie van triggers en stored procedures bijvoorbeeld goed nieuws. Hiermee kan op een abstracter niveau worden ontwikkeld, doordat bepaalde functionaliteit van software die van MySQL gebruik maakt verplaatst kan worden naar de database-engine. Ook views zijn toegevoegd, die het mogelijk maken om op basis van de opgeslagen gegevens virtuele tabellen te maken; code die gebruik maakt van meerdere tabellen kan daarmee flink vereenvoudigd worden. De ontwikkeltijd - doorgaans de belangrijkste kostenpost voor ontwikkelaars - kan daarmee fors worden verkort. Verder is er met de BIT een nieuw datatype voor booleans geïntroduceerd. Andere datatypes, met name de voor financiële data te gebruiken fixed-pointtypes, worden beter opgeslagen of verwerkt. Ook werd er een flinke serie optimalisaties - statements met OR, NOT IN, NOT BETWEEN, COUNT, MIN, MAX en GROUP BY zouden onder bepaalde voorwaarden significante winst boeken - aangebracht.

Veiligheid en compatibiliteit zou in de nieuwe versie een flinke vlucht nemen. Zo is tegenwoordig voorzien in een ANSI-modus, waarbij het gebruikte SQL-dialect meer in overeenstemming is met de standaardtaal, en de ondersteuning van transactions is uitgebreid. Toch zoekt MySQL nog steeds de underdog-positie op, en probeert het bedrijven als Oracle, IBM en Microsoft niet tegen het hoofd te stoten met uitspraken als 'wij leveren een toeristenklasse-database'. Het gevolg van die voorzichtige opstelling is wel dat MySQL Network, de betaalde variant, nog steeds in geen enkele gecertificeerde toepassing wordt toegepast. De verwachting is overigens wel dat certificatie van SAP niet lang meer op zich zal laten wachten.

Ondertussen wordt er in elk geval had gewerkt aan het opruimen van zoveel mogelijk bugs. MySQL heeft zelfs een heuse prijsvraag uitgeschreven om testers aan te moedigen: wie de meeste of de belangrijkste bugs vindt, maakt kans op een iPod nano, en wie daar bovendien leuke stukjes op een blog over schrijft, mag met het ontwikkelteam uit eten. Of dat laatste een effectieve aansporing is, zal uit de changelogs van na november moeten blijken.

Reacties (38)

[JivZ]

Ik snap niet waarom de introductie van stored procs goed nieuws is voor object georienteerd ontwikkelen. Dit staat helemaal los van elkaar.
Voor OO wil je liever abstracte datatypes en de mogelijkheid om Java code binnen de database te draaien (zoals in Oracle).

@EvilB2k: 1 bit is voldoende voor een boolean, maar dat betekent niet dat de database onderhuids ook 1 bit gebruikt. Waarschijnlijk wordt idd 1 byte gebruikt voor de opslag.

[d00d]

Ik weet niet hoe MySQL 1 bit wegschrijft maar SQL Server en Sybase gebruiken voor een boolean kolom 1 byte, en voor 2 boolean kolommen ook 1 byte, en voor 8 ook 1 byte. Pas bij de 9-de kolom wordt een tweede byte gebruikt. Efficienter kan niet...

[eborn]

Ik mag hopen dat MySQL dat ook doet (of gaat doen). Anders heeft een apart type voor BIT op zich weinig zin Behalve dan dat er een extra constraint voor 0/1 op zit.

[mxcreep]

Ehmm is JAVA soms de enige OO taal of zo ?

[Verwijderd]

Object georienteert programmeren staat los van Stored Procedures. Dat is waar.

Maar als je database objecten tussen verschillende applicaties wilt hergebruiken zijn Stored procedures daar een goede oplossing voor.

Dus het object georienteert programmeren wordt bevorderd door het beschikbaar zijn van Stored Procedures.

[Alex]

Als je hier zo sterk van overtuigd bent is het misschien interessant om dit topic eens te bekijken!

[Radiall]

Hoe kan het toch dat mensen het idee hebben dat MySQL geen zakelijke pretentie zou hebben en (bovenal) nergens in een zakelijke omgeving gebruik zou worden?

MySQL heeft al jaren een enorm zakelijke pretentie. Eén groot probleem alleen, veel van de MySQL utilities zijn slecht gedocumenteerd, waardoor de gemiddelde GUI modeller niet weet hoe hij te werk moet gaan en de voorkeur geeft aan het pleur en sleur van SQL server of Oracle.

Daarnaast.. zelfs de NASA heeft een datawarehouse van maar liefst 700GB draaien op MySQL server.. en wat zeggen ze er over? Hij is <b>'erg, erg snel'</b>..
Daarbij zijn ze vol lof over het feit dat MySQL geen system resource-vreter is zoals Oracle of andere database servers..

Zie ook: MySQL Breaks Into the Data Center

Hoezo, geen zakelijke pretentie? D'r is volgens mij maar één ding waar ze die kunnen uitbreiden.. hun marketing. Daar moeten ze het waar gaan maken.. de server kan de strijd allang aan!

[Parlor_Inventor]

Niet waar. Degene die een 700 GB datawarehouse draait en het "very, very fast" vindt is Mark Cotner, van Cox Communications....

[SED]

kijk even niet naar de kostenaspecten ( de belangrijkste reden om MySql te draaien) en je hebt een database die tot versie 5 ( en die moet zich nog bewijzen) op allerlei vlakken niet opgewassen is tegen een pakket als MS-SQL of Oracle.
Daar moet je nioet moeilijk over doen, dat is gewoon een feit.
versie 5 zou die achterstand moeten oplossen en dat is goed nieuws.

[J.J.J. Bokma]

Hoe meet jij dat opgewassen? Weer zo'n onzin kreet. MySQL kan bij veel toepassingen de voorkeur hebben boven MS SQL / Oracle. Dat moet per toepassing bekeken worden. Zomaar database X altijd uit de kast trekken omdat het lekker groot klinkt is dom.

[Verwijderd]

Het grote probleem is dat MySQL de basis principes van een database breekt. Het is gewoon niet ACID, Misschien dat versie 5 dat wel is, maar het feit dat het tot versie 5 geduurd heeft tot het tot de ontwikkelaars doordrong dat er basisprincipes zij waar een database zich aan te houden heeft spreekt niet in het voordeel van MySQL.

[Verwijderd]

Het grote probleem is dat MySQL de basis principes van een database breekt. Het is gewoon niet ACID, Misschien dat versie 5 dat wel is, maar het feit dat het tot versie 5 geduurd heeft tot het tot de ontwikkelaars doordrong dat er basisprincipes zij waar een database zich aan te houden heeft spreekt niet in het voordeel van MySQL

Sterker nog, ik vind dit eerder getuigen van hobbyisme of in elk geval het ontbreken van zakelijke compabiliteit.

Een database die al na 10 jaar!!! ontwikkeling nog steeds niet ACID compliant is maar het interessanter vind om eerder mode componenten zoals replication te ontwikkelen.... dat kun je toch niet serieus nemen?

Ik ben het wel met MySQL eens: "Wij zijn de IKEA in RDBMS land"
En dat klopt ook wel

[Verwijderd]

Daarnaast.. zelfs de NASA heeft een datawarehouse van maar liefst 700GB draaien op MySQL server.. en wat zeggen ze er over? Hij is <b>'erg, erg snel'</b>..
Daarbij zijn ze vol lof over het feit dat MySQL geen system resource-vreter is zoals Oracle of andere database servers..

Leuk, dat zegt al genoeg over de kwaliteit en gegevens controle over dat Datawarehouse.
Het feit dat MySQL weinig resources eet getuigt het ontbreken van enige overhead die je nodig hebt om complexe queries te draaien. Misschien dat Nasa gebruik maakt van een mega staging area en redundante klaarzet tabellen om zo te besparen in query processing tijd?

Het lijkt op het bekende oh zo snel te implementeren Garbarge in .. garbage out principe?? of de bron is de waarheid principe?
ja ja ja ja

[imp4ct]

Is MySQL 5 backwards compatibel met MySQL 4.x.x versies ?

[MetalRush]

Ik vraag mij juist sterk af hoe compatible het is met andere SQL smaken. Ik kan mij voorstellen dat een bedrijf (bijvoorbeeld uit kostenoverweging) best wel wil overstappen... maar hoeveel moeite / kosten zijn hiermee gemoeid... en ís het wel (goed) mogelijk?

[Verwijderd]

Triggers en stored procedures zal je moeten herschrijven.
Voor de rest moet je de SQL statements misschien licht aanpassen maar dat zou niet zo'n heel groot probleem hoeven te zijn.

Punt is meer of je bv SAP wil draaien op MySQL en hoe het met de performance zit. Maar bovenal of al deze nieuwe features nu wel eens enigszins volgens de standaard werken.

Tot slot bespaar je natuurlijk weinig kosten met zo'n operatie. Goede ontwikkelaars kosten geld en je moet eerst testen. De overstap kost dus in eerste instantie meer dan het opbrengt. Daar komt dan nog bij dat veel zakelijke backup software niet in staat is MySQL online te backuppen (dus terwijl de database doordraait) en krijg je daar dus een mogelijk probleem

[blade181]

Zakelijk betekent naar mijn mening dat het gebruikt kan worden voor zakelijke doeleinden.Niet zozeer de kleine projecten, maar echt de grote projecten waar performance en betrouwbaarheid heel nauw samen liggen. MySQL is goed, maar heeft nog niet de titel verkregen waardoor het misschien door wat grotere bedrijven gebruikt wordt. Daardoor dus nu ook een aantal nuttige upgrades.

Hoewel die certificering overigens niet veel zeggend is voor IT managers of gebruikers van databases, (de functies en eigenschappen, performance en betrouwbaarheid zijn de zaken waarnaar gekeken wordt) is het commericeel misschien wel een goed streven. Het is een soort referentie en daardoor misschien wel een opening om in grotere bedrijven gebruikt te worden.

[Verwijderd]

wat is dat toch met dat woord 'zakelijk' ? Betekent dat imcompetent of zo?
Met phpmyadmin kan je backups maken, wat een handige scripter kan automatiseren. Ze zijn wel bulky en vreten werkgeheugen maar dat kan je instellen. En je kan evt. mysqldump gebruiken als je je server goed configureert.

[Verwijderd]

arakrys: als je zelf mysql wat meer in een "zakelijke" omgeving zou gebruiken was je er misschien achter gekomen dat je gewoon 't cli-tooltje "mysqldump" kan gebruiken (wat een stuk beter werkt dan de dumps die phpMyAdmin uitspuugt, vooral in het geval van foreign key gebruik in InnoDB).

[J.J.J. Bokma]

Zakelijk is zakelijk, en daar wordt MySQL al jaren en jaren gebruikt. Sterker, MySQL is voor bepaalde toepassingen geoptimaliseerd, toepassingen die in zakelijk gebruik voorkomen.

MySQL is nooit een puur hobby of thuisgebruik database geweest, dus waar die onzin van zakelijke pretentie vandaan komt, geen idee.

[StefSybo]

Met mysqldump moet je een read lock op alle tabellen hebben en op dat moment kan er dus niet naar de database geschreven worden.
Je zou een tabel pas kunnen locken op het moment dat je die gaat backuppen en direct daarna unlocken, maar om een goede backup te krijgen moet je in het begin op alle tabellen een read lock verkrijgen en dan kan een tabel dus behoorlijk lang gelockt zijn.

Wat je wel zou kunnen doen is een replication slave opzetten om dumps van te kunnen maken zonder dat tabellen op de master gelockt moeten worden.

[Verwijderd]

ik krijg wel die indruk
misschien in ansi modus dat je problemen krijgt, maar normaliter zou het geen enkel probleem mogen zijn

[jochemd]

Nee, voor mij in elk geval niet. Dankzij een last-minute wijziging gedragen alle queries die gebruik maken van NATURAL of USING zich anders dan in alle voorgaande versies. Er is geen switch om deze wijziging aan of uit te zetten en de resultaten van deze queries zijn per definitie niet backward-compatible. (En MySQL 5.0.12 waar dit plotseling in kwam was nota bene een beta release, terwijl MySQL beweert dat in een beta alle SQL commands bevroren zijn.)

[Olaf van der Spek]

Dat is vaag, die betere ondersteuning van natural/using kan volgens mij prima samengaan met backwards compatibiliteit.

[Verwijderd]

Ik dacht dat het BIT datatype zowiezo al gebruikt werd voor booleans? En ik veronderstel dat het nog steeds 8 bits zijn om een boolean op te slaan.

[Laurens-R]

ehrm... 8 bits voor een boolean... daar is 1 bit al voldoende voor hoor

je weet wel:

true (1) - false (0)

1 bit met twee statussen

[Fossalta]

Probleem is dat het opslaan van een bit op een HDD of in memory niet kan (die werken immers met bytes), Je kunt wel 8 losse Bits kwijt in 1 byte, maar hiervoor zal dan eerst weer gebitshift moeten worden (wat weer meer tijd kost).

[J.J.J. Bokma]

Meer tijd? Hangt helemaal af van wat je doet, en is zomaar niet te zeggen. Daarnaast kan die tijd insignificant zijn voor de toepassing.

[perlboy]

Ben bang dat een database 2 bits voor een bitfield gebruikt. Het moet immers ook de waarde NULL kunnen herbergen.

[Verwijderd]

het zullen inderdaad 8 bits zijn, dat kan niet anders.
wat ik me wel kan voorstellen is dat het gebruik van meerdere bit kolommen achter elkaar geoptimaliseerd worden (dus 8 bit-kolommen zouden dan in 1 byte passen).

[Titusvh]

In geheugen sla je ook geen byte op.
Bijv. een Intel bak slaat alles minstens als 32 bits item op. Daar kan je dan wel weer losse bytes uit destilleren (Bijv 8 bits AL register benaderen is eigenlijk een deel van een AX register die weer een deel is van een EAX register (32 bits).

Geheugen idem dito: daar lees je minstens 32 bits uit, ook al defineer je een variabele van 1 byte/8bit.

Daar kan je dan ook een vervelend effect hebben.
Stel je hebt 3 8 bits variabelen en 1 32 bits: dan wordt het 32 bits item verspreid over de laatste 8 van een eerste geheugenpositie, de laatste 24 bits op de eerste 24 bits van een volgende 32 bits geheugen positie.

Gelukkig maken de compilers daar tegenwoordig korte metten mee (als je optimalisatie hebt aanstaan) en wordt elke variabele in een nieuwe 32 bits geheugenlokatie geplaatst. Je verspilt dan wel wat geheugen, maar dat is er tegenwoordig toch zat en het is beter voor je performance.

(In de meeste huidige talen voor win32 is een boolean gewoon 32 bits... over verkwisting gesproken...)

[farlane]

Ik vermoed dat het een integer type is, die iha meer dan 8 bits groot is.

[MaxxMark]

Ben ik ook benieuwd naar. Zeker als wij hier willen upgraden is het erg belangrijk dat we kunnen testen met een upgrade op een 'insignificant' slave.

Als dat niet het geval is denk ik dat het bij ons nog even zal duren voor we over gaan....

[Verwijderd]

"mag met het ontwikkelteam uit eten"

Dinner with nerds. Gezelli

[Wouter Tinus]

Als je op een website over MySQL schrijft is de kans groot dat je zelf ook een nerd bent .

<font size=-2>Hé Rat, hoe is ie ;)</font>

[sCHuTt]

Tja, als je al meegedaan hebt aan het debuggen in the first place...
Denk i wel dat de 'winnaar' in kwestie dit kan apprecieren

(bah, seconden te laat...)

[Olaf van der Spek]

Het Zweedse MySQL AB heeft met MySQL 5.0.13 de laatste Release Candidate van editie 5 van de populaire open-sourcedatabase uitgebracht. Als er geen grote problemen meer worden gevonden zal in november de definitieve release van MySQL 5 plaatsvinden.

Ik denk niet dat het de laatste RC is, aangezien de release van 5.0.14 zeer binnenkort is.
De developers werken al aan 5.0.15.

[maartene|IA]

MaxDB (http://www.mysql.com/products/maxdb/) is een open-source variant van MySQL die in samenwerking met SAP ontwikkelt wordt. Het is dan ook gecertificeerd voor gebruik met SAP software (en voor bepaalde toepassingen noodzakelijk!). Dat lijkt me behoorlijk enterprise grade.

Met Linux of Solaris 10 en MaxDB kun je aardig snijden in de kosten van een SAP installatie.