MySQL 5.0 bèta brengt langverwachte features

Reacties

« 1 2 3 »

Door jp, dinsdag 29 maart 2005 20:49

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

Door Alex, dinsdag 29 maart 2005 20:56

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?

Door blade181, dinsdag 29 maart 2005 21:14

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.

Door B-jorn, dinsdag 29 maart 2005 21:29

***ERROR***
devided by zero

Door Olaf van der Spek, dinsdag 29 maart 2005 22:03

***ERROR***
devided by zero

Prijs staat niet in de noemer. ;->

Door MBV, dinsdag 29 maart 2005 23:23

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

Door Myrdhin, woensdag 30 maart 2005 09:55

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

Door epauli, woensdag 30 maart 2005 10:15

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

Door Pietje Puk, woensdag 30 maart 2005 14:06

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.

Door Power2All, woensdag 30 maart 2005 23:32

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.

Door delenn, donderdag 31 maart 2005 11:45

MySQL wordt al jaren uitgegeven als commercieel pakket voor bedrijven.

Door Tukk, dinsdag 29 maart 2005 21:16

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.

Door StefSybo, dinsdag 29 maart 2005 22:10

Mysql draait ook op verschillende OS'en hoor

Door The Jester, dinsdag 29 maart 2005 22:16

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

Door StefSybo, dinsdag 29 maart 2005 22:23

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.

Door Olaf van der Spek, dinsdag 29 maart 2005 23:44

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.

Door DavidAxe, woensdag 30 maart 2005 22:00

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.

Door abraxas, dinsdag 29 maart 2005 20:54

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.

Door Arcane Apex, dinsdag 29 maart 2005 20:55

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.

Door epauli, dinsdag 29 maart 2005 20:58

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.

Door daft_dutch, woensdag 30 maart 2005 01:29

Gnuworld gebruikt postgresql doordat het veel sneller is dan mysql.

Door Alex, dinsdag 29 maart 2005 21:03

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

Door jp, dinsdag 29 maart 2005 23:14

SP's voeren stukken sneller uit dan losse queries

Door apa, woensdag 30 maart 2005 08:59

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.

Door DeKaluh, woensdag 30 maart 2005 09:21

@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.

Door Munters, woensdag 30 maart 2005 11:37

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.

Door Arcane Apex, dinsdag 29 maart 2005 21:08

@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).

Door henk_DE_man, dinsdag 29 maart 2005 21:32

"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?

Door Arcane Apex, dinsdag 29 maart 2005 21:40

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!"

Door KayJay, woensdag 30 maart 2005 08:32

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

Door Power2All, woensdag 30 maart 2005 23:43

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.

Door henk_DE_man, donderdag 31 maart 2005 14:56

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?

Door carlo, woensdag 30 maart 2005 09:11

"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.

Door Pietje Puk, woensdag 30 maart 2005 14:18

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.

Door Arcane Apex, woensdag 30 maart 2005 14:35

@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.

Door ESP tech, dinsdag 29 maart 2005 20:55

Als je gratis wilt dan kijk naar firebird. Meer en beter dus.

Door GSteven, dinsdag 29 maart 2005 21:09

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.

Door MisterData, dinsdag 29 maart 2005 21:17

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

Door XirioTroniX, dinsdag 29 maart 2005 21:25

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

Door --MeAngry--, woensdag 30 maart 2005 09:00

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.

Door henk_DE_man, dinsdag 29 maart 2005 21:23

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.

Door StefSybo, dinsdag 29 maart 2005 22:17

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.

Door Sfynx, woensdag 30 maart 2005 02:19

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

)

Door jeroen123, woensdag 30 maart 2005 11:26

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?

Door KayJay, woensdag 30 maart 2005 13:33

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.

Door Afterlife, dinsdag 29 maart 2005 21:30

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!

Door El_Muerte_[TDS]541, dinsdag 29 maart 2005 22:07

SQL:2003 style

wth is dat?

Ik ken alleen SQL92 (aka SQL2) en SQL3.

Door ArnoBrinkman970, woensdag 30 maart 2005 01:59

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

Door 0siris, dinsdag 29 maart 2005 21:55

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>

Door zeroxcool, dinsdag 29 maart 2005 22:00

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.

Door _Thanatos_, dinsdag 29 maart 2005 22:46

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.

Door KayJay, woensdag 30 maart 2005 08:40