MySQL 5.0 bèta brengt langverwachte features

Vandaag heeft MySQL AB een nieuwe mijlpaal bereikt in de ontwikkeling van de gelijknamige databaseserver met de introductie van de eerste bètaversie van MySQL 5.0. Ten opzichte van voorgaande versies zijn de veranderingen legio. Het meest vallen echter de nieuwe features op die vooral gericht zijn op grotere bedrijven. Zo is door de ontwikkelaars ondersteuning toegevoegd voor views, stored procedures en triggers. Volgens David Axmark, een van de oprichters van MySQL, is de databasesoftware door velen al sinds 1995, toen de basis voor MySQL gelegd werd, bekritiseerd omdat onder meer deze features niet aanwezig waren. Uit onderzoek van Evans Data Corporation, dat in januari gepubliceerd is, blijkt dat MySQL de meest gebruikte open-sourcedatabase is met zijn marktaandeel van 40 procent. Concurrent Firebird heeft 39 procent van de markt in handen en PostgreSQL bezit 11 procent van deze markt. Axmark verwacht dat het aantal gebruikers van MySQL sterk zal toenemen als de final versie van MySQL 5.0 deze zomer gelanceerd zal worden.

Reacties (86)

[Arcane Apex]

De absentie van een aantal high-end database features in mySQL is ook een reden dat mySQL de snelste database is onder de andere grote concurrenten.
In een face-off benchmark tussen mySQL en PostgreSQL bleek tot voor kort mySQL 100x sneller queries te kunnen verwerken, met versie 8.0 heeft PostgreSQL dat kunnen terugdringen tot 20x.
Echter PostgreSQL bezat/bezit wel alle high-end features zoals database giganten als Oracle hebben.

Maar als het zo is dat mySQL deze geavanceerde features kan implementeren zonder snelheidsverlies te lijden of slechts een klein snelheidsverlies te incasseren dan zou mySQL wel eens een monopolie kunnen gaan hebben, omdat veel corporate backend-beheerders tot nu toe nog voor andere databases kozen, omdat ze gewoonweg de geavanceerde features nodig hadden, maar als mySQL dit ook gaat aanbieden en daarbij tevens nog de snelste database blijft, dan kan de concurrentie wel eens wegsmelten.

[Arcane Apex]

@Edwin P.

http://www.databasejournal.com/features/mysql/article.php/3288951


"They quickly install a default installation, run a few benchmarks, and find PostgreSQL to be 50 (0r 100, or 1000) times slower."


Echter moet erbij gezegd worden dat dit in een context staat wanneer zowel mySQL en PostgreSQL out of the box geinstalleerd worden en niet worden finegetuned.
Men kan immers de snelheid van PostgreSQL finetunen, maar dit is ook het geval voor mySQL, maar men heeft het hier dus over out of the box installs.(van beide DB's)

Maar als men ziet dat PostgreSQL in 1 versie een sprong kan maken in snelheid van 400-500% ten opzichte van de vorige versie, dan zal PostgreSQL binnen een aantal versies op dezefde snelheid als mySQL zitten en tevens al zou mySQL al de beloofde geavanceerde features implementeren in mySQL 5, dan nog heeft PostgreSQL meer geavanceerde features waar mySQL pas over gaat nadenken in versie 6 of 7, dus qua features zit PostgreSQL wel op een hogere positie dan mySQL, waarschijnlijk ook de komende releases van mySQL(6 en 7).

[Verwijderd]

"They quickly install a default installation, run a few benchmarks, and find PostgreSQL to be 50 (0r 100, or 1000) times slower."

Dit is echt grote onzin. Ten eerste, wat is het nu, 50, 100, of 1000x? Dat is zo'n significant verschil dat je dat niet even op die manier kunt zeggen.

Ten tweede slaan die factors echt absoluut nergens op. Het is zo'n totale onzin dat ik me afvraag waarom ik er eigenlijk serieus op probeer in te gaan, maar het feit is dat mysql slechts voor hele specificieke queries marginaal sneller is. Dat zijn dan de ultra simpele select queries direct uit een enkele tabel.

Komen er group-by dingen in, met complexe counts, sub selects, meervoudige joins (bv via koppeltabellen zijn 6 joins in genormaliseerde DBs de normaalste zaak van de wereld), etc etc, dan blijft er van die zogenaamde performance van mysql helemaal niks meer over.

Denk je eens in man, als serieuze bedrijven velen man-uren spenderen of de execution time van een query met een factor 4 omlaag te brengen door veel optimalisaties en heel veel slim nadenken (lees, veel tijd), en mysql zou daar even met een factor 1000 overheen gaan? Dan zou toch geen enkele serieuze developper postgresql meer gebruiken?

[Arcane Apex]

Dit is echt grote onzin. Ten eerste, wat is het nu, 50, 100, of 1000x? Dat is zo'n significant verschil dat je dat niet even op die manier kunt zeggen.

Ten tweede slaan die factors echt absoluut nergens op. Het is zo'n totale onzin dat ik me afvraag waarom ik er eigenlijk serieus op probeer in te gaan

Zulke benchmark-software test de databases waarschijnlijk onder verschillende omstandigheden.
Het kan zijn dat bij een bepaald type query mySQL 50x sneller is en in een ander extreem type query zelfs 1000x.
Dat wil nog niet zeggen dat mySQL in alle gevallen 1000x sneller is.

Je kan de reviewer van dat artikel er ook op aanspreken door hem te mailen.
Aan het eind van het artikel schijnt hij zelf aan te geven om hem te bekritiseren op bias als je hem daarop betrapt.

"In the interests of transparency, I have to confess to having used MySQL much more than PostgreSQL, so feel free to reread the article to scour for instances of my obviously blatant bias!"

[Verwijderd]

Lekkere quote

Wat uitgebreider

To add fuel to the fire, Person A now responds to the criticism, and loads PostgreSQL. They quickly install a default installation, run a few benchmarks, and find PostgreSQL to be 50 (0r 100, or 1000) times slower. No consideration is given to the fine-tuning required to get any application to perform optimally. Their preconceptions cemented, PostgreSQL is forevermore dog slow. Or the reverse. Even experienced users find benchmarks tricky to evaluate, as an article by Tim Perdue, and the subsequent comments, showed. In benchmarks he ran, he found that PostgreSQL 7.1 was faster than MySQL 3.23.26beta (both versions are now seen as from the ark, so don't get excited by the details). The variety of responses was again interesting, people supporting 'their' database of choice, usually without much foundation.

Ja, ja begrijpend lezen blijft moeilijk. En mensen die onzin naar +4 waarderen.

[Arcane Apex]

@Carlo & Pietje Puk

Het kan inderdaad zo zijn dat de schrijver van het artikel die cijfers figuurlijk bedoelde.
Wellicht heb ik iets te snel die getallen gebruikt.

Mijn excuses.

[Verwijderd]

Zulke benchmark-software test de databases waarschijnlijk onder verschillende omstandigheden.
Het kan zijn dat bij een bepaald type query mySQL 50x sneller is en in een ander extreem type query zelfs 1000x.
Dat wil nog niet zeggen dat mySQL in alle gevallen 1000x sneller is.

dit soort tests zeggen inderdaad geen hout. daarin ben ik het met henk eens.
er worden vaak tests gedaan zoals select * from table;
ja dan is mysql wel sneller ja.
Vooral als het één user is.
Het verschil zit hem gewoon in de overhead.
een snelle db zoals mysql gaat door het ontbreken van die overhead het erg moeilijk krijgen bij complexe taken.
Een RDBMS zoals Oracle, DB2 of PostgreSQL heeft die overhead wel, waardoor deze bij simpele taken trager is maar bij bijvoorbeeld de complexe autonome transacties een stuk vlotter loopt.
Ik denk dat een complexe transactie die hier 4 uur loopt op Oracle écht niet vlotter loopt op MySQL. sterker nog, ik denk dat, áls hij alle features zoals views, triggers en SP's aan boord zou hebben, nog trager is dan 4 uur.

Maar laten we het eens over een andere brug gooien:
concurrent connections!!
dan begint MySQL bij rond de 20 wel te kreunen.. en postgres loopt daar gewoon met nauwelijks verlies mee door.
Gaan we inderdaad wat complexere queries maken dan gaat de performance van Mysql naar beneden als een baksteen.
bij de inserts is MySQL ook niet zo rap overigens.
Verder mist MySQL buiten views , stored procedures en database triggers nog veel meer elementaire zaken die db's zoals Oracle en Postgresql wel hebben.

en oh ja.. ik heb meer mysql dan postgresql gebruikt en op de wat grotere db vind ik postgres toch wél een verademing..

[Verwijderd]

Hier ben ik het niet mee eens. Ik gebruik zelf MySQL en met je 1 user effe zoeken. Ik heb ongeveer 30000 users met 40000 torrents (torrent tracker) volledig php en MySQL based. Ik denk als je dat in PostgreSQL gaat draaien, je een stukken langzamer bent, maar tja, ik heb PostgreSQL 1x gebruikt, mag je 1x raden waarom ik er niet mee doorging. Niemand heeft (behalve dan diegene die denken het beter te weten) een script geschreven (zover ik de scripts ken die aanwezig zijn) die werkt onder PostgreSQL. Pas veel later zag ik bekende forums zoals phpBB (volgensmij nog steeds niet) en InvisionBoard overschakelen naar ondersteuning voor PostgreSQL.

Nog even over die benchmarks, ik werk bij een groot bedrijf die winkels beheren in Engeland enne, die gebruiken idd gewoon MSSQL. Ik heb hier ook discussies gehad over Oracle, MySQL, MSSQL en PostgreSQL. Daaruit kwam gewoon dat MySQL niet gekozen was omdat het opensource was en PostgreSQL was nog niet eens bekend bij ze. MSSQL was goedkoop omdat ze hier ook goede ondersteuning hadden en ze draaien nu eenmaal Windows. Oracle is gewoon $$$$ en de gebruiksvriendelijkheid van Oracle is gewoon belabberd slecht.

[Verwijderd]

Hier ben ik het niet mee eens. Ik gebruik zelf MySQL en met je 1 user effe zoeken. Ik heb ongeveer 30000 users met 40000 torrents (torrent tracker) volledig php en MySQL based. Ik denk als je dat in PostgreSQL gaat draaien, je een stukken langzamer bent, maar tja, ik heb PostgreSQL 1x gebruikt, mag je 1x raden waarom ik er niet mee doorging.

Maar wat is dan de structuur van je queries? Alleen simpele data fetches uit een enkele tabel?

Hoeveel joins heeft jouw typische query? Hoeveel sub-queries gebruik je? Gebruik je group by en counts in die sub-queries?

Of ben je zo iemand die helemaal geen SQL schrijft en alleen standaard scriptjes en software weet te gebruiken?

[carlo]

"They quickly install a default installation, run a few benchmarks, and find PostgreSQL to be 50 (0r 100, or 1000) times slower."


Echter moet erbij gezegd worden dat dit in een context staat wanneer zowel mySQL en PostgreSQL out of the box geinstalleerd worden en niet worden finegetuned.

Dit is mis-informatie!!! Arcane Apex haalt hier een quote uit het artikel alsof dit het resultaat van een test zou zijn, dat is niet waar! De auteur van het originele artikel probeert hier iets geheel anders duidelijk te maken en de namen van PostgreSQL en de genoemde getallen zijn slechts verzonnen voorbeelden, niet de resultaten van een test. oid.

[Alex]

Maar als het zo is dat mySQL deze geavanceerde features kan implementeren zonder snelheidsverlies te lijden of slechts een klein snelheidsverlies te incasseren dan zou mySQL wel eens een monopolie kunnen gaan hebben, omdat backend-beheerders tot nu toe nog voor andere databases kozen, omdat ze gewoonweg de geavanceerde features nodig hadden, maar als mySQL dit ook gaat aanbieden en daarbij tevens nog de snelste database blijft, dan kan de concurrentie wel eens wegsmelten.

Het nodig hebben van features als views, triggers en stored procedures vind ik een slap excuus. Inprinciepe kan alles vanuit de code die gebruikt maakt van deze zaken.
Het is imemrs zo dat als er een tabel verandert, of een veld verandert in het geval van een stored procedure, trigger en view nog 90% van de tijd de code ingedoken moet worden omdat er speciale casts op de database output zitten of dat de resultaten aangeroepen worden met nummertjes.

Belangrijker vind ik ofdat MySQL met deze extra zaken ook de stabiliteit van een 'echte' database kan vinden en zich daarmee mengen met databases als SQL Server, DB2 en Oracle.
Even de Open Source varianten daar gelaten. Aangezien die toch wat minder worden gebruikt voor midden segment en highlevel oplossingen.
De vraga is of MySQL met zo'n breed scala aan functies zich daarin kan mengen. Het is niet zo dat beheerders featuregeil zijn...

Edit:
De beheerders zijn immers geen developers

[apa]

SP's voeren idd een stuk sneller uit dan losse queries zoals jp correct aangeeft (dat is in alle geval al zo in MS SQL). Daar zijn een aantal redenen voor:

* De interpretatie en validatie van de query-code moet niet iedere keer opnieuw gebeuren. Deze kan nu gebeuren op het moment van creatie van de SP.

* De DBMS kan een query-plan bijhouden voor iedere stored procedure. Het query-plan kan dan geomptimaliseerd worden voor iedere stored procedure op basis van statistieken die bijgehouden worden bij het runnen van de stored procedure.

Dit alles vervalt overigens in MS SQL wanneer je EXEC's van varchar's opneemt in de stored procedure: dan krijg je namelijk volledig dynamische queries.

[Verwijderd]

@Apa
Queries worden bij MS SQL Server ook gecompileerd gecashed als je geparameteriseerde queries gebruikt via de sp_executesql stored procedure (en je fully qualified table names gebruikt, belangrijk detail). En in het .NET framework wordt onder water de sp_executesql zelfs voor je aangeroepen.

Het nodig hebben van features als views, triggers en stored procedures vind ik een slap excuus. Inprinciepe kan alles vanuit de code die gebruikt maakt van deze zaken.

@Alex
Views een slap excuus? Het fijne van een view is, dat je daar een hoop standaard join relaties in kunt zetten. Heb je een beetje een redelijke database, dan krijg je zonder views al snel lompgrote queries in je code. Views maken je code dus overzichtelijker en versnellen het ontwikkelproces.
Niet geheel overbodig dus lijkt mij.

[Munters]

En views zijn heel handig om de compatibiliteit te bewaren.
Als je rapporten of programma's op views baseert (die desnoods 1-op-1 mappen op de tabellen), kun je daarna de databaseopzet aanpassen en zorgen dat de views deze wijzigingen maskeren.

[jp]

SP's voeren stukken sneller uit dan losse queries

[Verwijderd]

In een face-off benchmark tussen mySQL en PostgreSQL bleek tot voor kort mySQL 100x sneller queries te kunnen verwerken, met versie 8.0 heeft PostgreSQL dat kunnen terugdringen tot 20x.

Waar haal jij vandaan dat PostgreSQL 20 tot 100 keer langzamer is dan MySQL?
Ik geloof er niks van.

[daft_dutch]

Gnuworld gebruikt postgresql doordat het veel sneller is dan mysql.

[Verwijderd]

Leuk dat mysql wat verder gaat met de ontwikkeling, maar persoonlijk snap ik eigenlijk helemaal niet waarop iemand uberhaupt mySql zou willen gebruiken.

Mysql is wel opensource, maar niet gratis voor commercieel gebruik. Bedrijven met een krap budget zouden dus wel gek zijn om hiervoor te kiezen. Zowel firebird als postgresql zijn wel gratis, en hebben ook nog eens een veel volledigere implementatie van SQL + veel extra features.

Kortom, waarom zou je voor iets betalen en er dan nog minder voor krijgen ook?

Als je dan al wilt (kunt!) betalen voor een DBMS, dan kies je toch eerder voor iets als Oracle of Db2. Dan heb je nog betere enterprise features dan postgresql (oa clustering) en bovendien meer mogelijkheden voor support als je dat nodig hebt.

De enige reden dat mysql zo'n groot marktaandeel heeft is IMNSHO vanwege de koppeling met PHP en het beschikbaar zijn onder Windows. Een groot gedeelte van dergelijke gebruikers (en zeker in die combinatie) zijn toch amateurs. Amateurs gebruiken die DB alleen maar voor hele simpele retrieval queries. Echt complexe dingen waar veel joins bij komen kijken en veel sub-queries zijn aan dergelijke lieden absoluut niet besteed.

De reacties van sommige zijn dan ook heel typerend:

Daarnaast zijn ze niets meer als een opslag methode.Volgens keer doen je die opslag op objectniveau of gewoon filebased. Kan allemaal.

Ik ga hier maar niet eens inhoudelijk op in, maar het feit dat je voor Oracle toepassingen af en toe met niet minder dan een quad bak wegkomt zegt waarschijnlijk wel genoeg.

Als je kijkt naar het markaandeel van DBMS's bij serieuze developpers & bedrijven, dan zie je opeens een heel ander beeld. Zowel postgresql als oracle blijken dan opeens het meeste marktaandeel te hebben.

Mischien dat het feit dat postgresql tegenwoordig ook onder Windows draait, het wat meer marktaandeel bij de n00bs zal geven. Blijft natuurlijk sterk de vraag of je eigenlijk wel wat hebt aan aandeel in dat laagste marktsegment.

[StefSybo]

Mysql is wel opensource, maar niet gratis voor commercieel gebruik.

MySQL is wel gratis voor commercieel gebruik, alleen als je support wil of de code wil wijzigen zonder die wijzigingen vrij te geven moet je een commerciele licentie nemen.

[Sfynx]

De enige reden dat mysql zo'n groot marktaandeel heeft is IMNSHO vanwege de koppeling met PHP

In de PHP-suite zitten standaard extensions voor MySQL, MS SQL, PostgreSQL, Oracle, en een hoop andere zijn mogelijk via een ODBC-extension (Access, IBM DB2, etc). Dus die reden valt af.

Ik ben het met je eens dat MySQL misschien bij de wat ingewikkeldere queries niet de snelste is, maar is dat altijd nodig voor een professionele toepassing?

(P.S: persoonlijk weiger ik te werken met een DBMS onder Windows, ik vind MySQL een stuk beter werken onder UNIX/Linux )

[Verwijderd]

Mysql is wel opensource, maar niet gratis voor commercieel gebruik. Bedrijven met een krap budget zouden dus wel gek zijn om hiervoor te kiezen.

Eén woord: support. Denk je dat een bedrijf zo gek is om z'n belangrijkste goed (data) in een database te steken waarvoor ze niet de fabrikant even kunnen opbellen als er een probleem is?

En de licentie + support van een Oracle is toch net dat ietsje duurder dan die van MySQL veronderstel ik, dus als je met die functies toekomt...

Wat je zegt klopt trouwens niet: bij MySQL moet je enkel betalen voor support, commercieel gebruik blijft voor de rest gratis. Net zoals je voor PostgreSQL support kan krijgen (maar dan van derden).

[edit]
Nog vergeten te melden:

Er is totaal geen reden om een Oracle DB te gebruiken als je ook toekomt qua functionaliteit met MySQL. MySQL is snel, stabiel, heeft geen quad-bak nodig en doet meer dan genoeg voor kleine en middelgrote projecten. Net zoals een gewone file of object-based opslag ook een oplossing kan zijn. Je gaat toch ook niet met een Boeing 747 naar de kruidenier om de hoek?

[Verwijderd]

Er is totaal geen reden om een Oracle DB te gebruiken als je ook toekomt qua functionaliteit met MySQL. MySQL is snel, stabiel, heeft geen quad-bak nodig en doet meer dan genoeg voor kleine en middelgrote projecten. Net zoals een gewone file of object-based opslag ook een oplossing kan zijn. Je gaat toch ook niet met een Boeing 747 naar de kruidenier om de hoek?

Ik mag aanemen dat bij kleine klanten of kleine projecten de data integriteit ook gewaarborgt moet blijven. Zolang MySQL nog niet fatsoenlijke transacties ondersteunt zul je veel erom heen moeten bouwen wil je dat goed krijgen.

Het verhaal over de boeing loopt op dat gebied al mank.

[Verwijderd]

ik ben vooral benieuwd naar de performance, aangezien mysql in den beginne waarschijnlijk niet heel erg geoptimaliseerd is opgezet voor dit soort nieuwe zaken... het zou mijns insziens wel eens kunnen tegenvallen.

[ulevasa]

Ook lezenswaardig:

http://www.yapf.net/faq.php?cmd=100&itemid=832

[jp]

Nu MySQL dus blijkbaar volwassen wordt, tijd voor een grondige vergelijking tussen een lading DBMS'en

[Alex]

Het is vrij lastog om een vergelijking te maken van dergelijke DBMS-en. Ga je dit qua snelheid doen? Ga je dit naar ratio van opslag/snelheid doen? Ga je dit doen op het gebied van features? Je kunt dit zelfs doen op het gebied van de SQL standaard van '92.
Wat wil je ervan weten?

Voor 9 van de 10 developers zal het een rotzorg zijn of ze SQL Server of MySQL gebruiken. Waarom? Qua snelheid zijn ze, mits juiste database structuur, beide even snel. Daarnaast zijn ze niets meer als een opslag methode.
Volgens keer doen je die opslag op objectniveau of gewoon filebased. Kan allemaal.

Het lastige is gewoon hoe je deze zaken wilt vergelijken. Wat vind je tegen elkaar opwegen? Hoe reeël is het als je een CPU stressed en hoe reeël is het als je 1 miljard records probeert in te voeren achter elkaar?

[blade181]

Ik ga het vergelijken qua prijs/kwaliteit, dit is een goed voorbeeld van open source software dat steeds meer volwassen wordt. Je kunt duidelijk zien dat er goed geluisterd is naar de klant.

[Verwijderd]

***ERROR***
devided by zero

[Verwijderd]

Open Source betekent niet dat het gratis is, maar dat de source code openlijk beschikbaar is.

[Verwijderd]

Dus het is opensource.
Vrij te krijgen en zelfs gecompileerd en iedereen gebruikt het.
Het is gratis, maar er zal vast wel zoiets komen als Enterprise edition of zo.

[Olaf van der Spek]

***ERROR***
devided by zero

Prijs staat niet in de noemer. ;->

[MBV]

Jij stelt kwaliteit op 0? Van wie?
...
Oh ja, het was Tweakers.net. MS kwaliteit is zeker nul


dit is geen flame naar MS, maar naar de algemene reacties die soms naar voren komen op tweakers

[Myrdhin]

Lekker dan, de prijs/kwaliteit voor open source software is 0

[Verwijderd]

Na 10 jaar. Dat noem ik niet luisteren naar je klant. Meer to little to late. Er zijn twee prima alternatieven die bewezen hebben dat hun implementaties geschikt zijn voor serieus gebruik. MySQL heeft de afgelopen 10 jaar bewezen zelfs te instabiel te zijn voor grotere websites.

[delenn]

MySQL wordt al jaren uitgegeven als commercieel pakket voor bedrijven.

[Tukk]

Het is mischien niet reeel, maar geeft je wel een idee wat je er mee kan.

Door mijn ervaring met MSSql en Oracle weet ik de verschillen tussen beiden. Voorbeelden van verschillen:

- Mssql is goedkoper out of the box (meestal, ligt aan verschillende dingen)
- Oracle is beter beheersbaar
- Oracle is mulit-Os

enzevoort.

Maakt dat 1 van de 2 beter, nee. Maar als ik voor een bepaald gebruik wil gebruiken weet ik wel welke ik moet hebben.

Door de door jouw opgegeven vergelijkingen te bekijken kun je dan meer inzicht krijgen in welk DBMS nuttig is voor welke taak.

[StefSybo]

Mysql draait ook op verschillende OS'en hoor

[The Jester]

Een belangrijker verschil is de schaalbaarheid:
MySQL werkt prima, behalve bij zeer grote Dbases. Een ander nadeel is dat de default table een MyISAM is (hoewel dit wordt veranderd in InnoDB) en dat heeft weer gevolgen ivm mutaties en concurrent lees- of schrijfacties.

Voor de meeste personen en bedrijven zal MySQL prima voldoen, zolang je maar zorgt dat je de juiste tables genereert (InnoDB) en de boel niet te groot wordt. Voor Windozegebruikers die over willen stappen van ODBC naar MySQL is nóg een beperking: MySQL is, in tegenstelling tot MS-Access case sensitive. Da's lullig wanneer je wilt migreren...

[StefSybo]

In MySQL > 4.1 kan je voor elke kolom van een tabel kiezen welke karakterset je wil gebruiken en daar zitten er ook bij die case insensitive zijn, sterker nog: de default is latin1_swedish_ci, die case-insensitive is.

[Olaf van der Spek]

In MySQL > 4.1 kan je voor elke kolom van een tabel kiezen welke karakterset je wil gebruiken

Dit gaat over database- en tabelnamen, niet over veldwaarden.

[DavidAxe]

Het lijkt me stug dat het 9 van de 10 developpers wat uit zou maken of ze MySQL of MS SQL server gebruiken, want nu pas ondersteunt MySQL alle belangrijke SQL commando`s. Voor MySQL versie 5 waren subqueries niet eens mogelijk en dat is toch vrij essentieel.
Zelf ben ik vooral liefhebber van Opensource producten, maar bij MySQL miste ik tot voor kort echt transactions en subqueries.

[GSteven]

En hoe zit het in verband met de compatibiliteit met de vorige versie's, voor inzake PHP scripts?

Veel scripts werkten niet meer na de overschakeling naar versie 4. Alhoewel het in mijn ogen nogal meeviel... maar toch.

[MisterData]

Voorzover ik weet kwam dat vooral omdat de client-library die bij PHP zat nogal oud was (/is?) en niet meewerkte omdat de MySQL server een nieuwe vorm van password-encryptie gebruikt die de client-libs nog niet snapten

[Verwijderd]

Dit probleem is eenvoudigweg op te lossen door in de MySQL console het volgende te typen:
SET PASSWORD FOR
-> 'some_user'@'some_host' = OLD_PASSWORD('newpwd');

weg probleem

[--MeAngry--]

In PHP 5.0.3 zit eindelijk weer een bijgewerkt libmysql.dll/so zodat je niet ineens mysqli hoeft te gebruiken om ook van MySQL 4.1 en hoger gebruik te kunnen maken.

[Verwijderd]

Uit de genoemde link:
Basic support for read-only server side cursors.
Basic support for (updatable) views.
Basic support for stored procedures (SQL:2003 style).
Initial support for rudimentary triggers.

Nog niet meteen je Oracle, DB2, Informix, MSSQL, etc. databases overzetten dus...
Maar ja, 't is ook nog een vroege beta, en het begin is er.

Als ze de snelheid en beheersbaarheid een beetje op peil weten te houden, kan 't wel een toppertje worden. Ik ben benieuwd!

[Verwijderd]

SQL:2003 style

wth is dat?

Ik ken alleen SQL92 (aka SQL2) en SQL3.

[Verwijderd]

SQL2003 is de opvolger van SQL99 en bevat ondermeer de PSM (Persistent Stored Modules) documentatie.

[0siris]

In hoeverre is dit een vooruitgang voor het T.net serverpark?
<edit>m.a.w. kunnen de features in v5 een bijdrage leveren aan de eenvoud/beheersbaarheid/snelheid van het T.net serverpark?</edit>

[zeroxcool]

Op korte termijn zal dit niets uitmaken, je gaat op een productie omgeving uiteraard geen bètas draaien. Voordat MySQL 'echt' stable wordt, zal er nog wel zeker een jaartje overheen gaan.

Met echt stable bedoel ik overigens dat een aantal gerenomeerde sites (want dat zijn naar mijn mening de echte productie omgevingen omtrent een MySQL database) het stabiel en sneller hebben draaien.

[_Thanatos_]

Ik denk dat t.net erop vooruit kan gaan als MySQL 5 stable verklaard wordt. Met views is het programmeren tegen joint tables aan veel makkelijker en omdat je views ook kan indexen (hopelijk) zal dat ook weer sneller zijn. Subqueries kunnen in 4.1 al, maar ik hoop dat ook derived tables mogelijk worden, maakt de boel ook weer makkelijker en sneller. En tot slot natuurlijk de stored procedures. Toen ik relatief complexe queries in SP's ging omzetten, onstond er een explosie in snelheid! Dat was dan wel met MSSQL, alwaar SP's gecompileerd worden. Hopelijk doet MySQL dat ook.

[Verwijderd]

Met views is het programmeren tegen joint tables aan veel makkelijker en omdat je views ook kan indexen (hopelijk) zal dat ook weer sneller zijn

Views kun je niet indexen, en al zeker niet als er outerjoins in staan.

[_Thanatos_]

En staat dat wel in de planning dan? Want de commerciele RDBMS'en kunnen dat dus wel. Volgens mij ook als er joins in de view zitten.

[_Thanatos_]

Zo is door de ontwikkelaars ondersteuning toegevoegd voor views, stored procedures en triggers

Waarom is dat alleen voor grote bedrijven? Iedereen die ze wel kan gebruiken, maar dat niet doet, zou gauw terug moeten naar de kleuterschool!

[CyberSnooP]

Voor de gemiddelde mkb-website zijn stored procedures of triggers misschien best hier en daar toe te passen maar doe je dat niet om extra complexiteit uit te sluiten. Als je programmatuur door iemand van de kleuterschool nog te begrijpen is ben je juist goed bezig (imho).

[SvMp]

Ik ben het wel met _Thanatos_ eens. Als je in PHP een site maakt, dan kan een view je heel wat PHP-werk besparen. Volgens mij bespaar je ook flink processorkracht als je complexe queries zoveel mogelijk aan MySQL overlaat (dus zo weinig mogelijk afzonderlijke query's vanuit PHP, zodat PHP geen tabellen door hoeft te lopen en weer nieuwe query's doen om uiteindelijk de gevraagde gegevens te verzamelen -> met een view kan dat in 1 query).

[Verwijderd]

Met een of meerdere views kunnen een boel dingen in 1 query. Gecombineerd met sub-queries kan bijna alles in 1 enkele query uitgedrukt worden.

In het enterprise systeem waar ik (profesioneel) aan werk hebben we een verzameling van honderden queries. Op slechts enkele uitzonderingen na levert elke query direct het gewenste resultaat op. Rijen aflopen en dan nog gaan rekenen aan de aplication server kant is dus niet van toepassing. Mischien onnodig om te zeggen dat de SQL code als volwaardig onderdeel van de source code wordt gezien en niet slechts een data-fetch commando'tje is. Sommige queries zijn makkelijk meer dan 100 regels lang.

En nee, we gebruiken geen mysql...

[Verwijderd]

Op welke pagina kan ik meer vinden over de prijzen/kosten van deze database?

[zeroxcool]

MySQL is veelal gratis te gebruiken. Maar hier vind je wat extra informatie omtrent de MySQL license:

http://www.mysql.com/company/legal/licensing/opensource-license.html
en hier
http://www.mysql.com/company/legal/licensing/commercial-license.html