MySQL stapt in gat dat Microsoft achterlaat

Doordat Microsoft zich op het gebied van databases steeds meer op het grote werk gaat richten, krijgt MySQL de kans om op de low-end markt terreinwinst te boeken, zo laat C|Net weten. Tot een paar jaar geleden was MySQL nog de grote onbekende bij bedrijven als het om databases ging, namen als Oracle en IBM waren de gevestigde orde. Tegenwoordig wordt steeds vaker naar MySQL gegrepen als database-oplossing vanwege onder andere de kleinschaligheid en kosten. De toekomst van MySQL ziet er rooskleurig uit met een omzet van tien miljoen euro vorig jaar, en verschillende vernieuwingen die op stapel staan.

Zo zal MySQL binnenkort een cluster-versie van zijn databasesoftware introduceren, evenals een grafische beheertool. Met die clusterversie hoopt MySQL meer grote bedrijven te interesseren voor zijn databasesoftware, en zo dus meer marktaandeel te verkrijgen. Nu Microsoft bezig is om marktaandeel van de grote jongens zoals Oracle en IBM weg te snoepen met zijn databasesoftware, wil MySQL zijn marktaandeel in het low-end segment gaan vergroten.

Reacties (85)

[Morphine]

Wie van onze PHP scripters gebruikt MySQL nou niet? Ik werd er zelfs op school in opgeleid, dus dit gevolg leek me voorspelbaar

Vraag me toch af hoe MySQL zoveel geld verdient aan een freeware pakket

[thegve]

Lol, ik wilde een tijdje geleden voor commercieel gebruik zo'n mysql sever gebruiken, dat is ook echt niet gratis hoor. Gratis is het alleen voor ontwikkelaars en voor als je zelf een servertje thuis wilt starten. Maar dan natuurlijk juridisch verantwoord omschreven.

[seweso]

Correctie: Het is wel degelijk mogelijk om in een commerciele applicatie (mét gesloten source) mysql te gebruiken:

Free use for those who never copy, modify or distribute. As long as you never distribute (internally or externally) the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not.

Dit geld dus eigenlijk voor alle web-diensten...lijkt me.

[sys64738]

Op mn werk hebben we het een keer uitgezocht. Het is inderdaad gratis te gebruiken voor commerciele doeleinden, zolang je het voor een maatwerk-oplossing gebruikt.
Zodra je het onderdeel wilt maken van een standaard software-pakket dat gewoon in de winkel te koop is, komen er licentiekosten om de hoek kijken.

[Verwijderd]

Zolang MySQl 4.1 in alpha is is postgresql veruit superieur aan mysql. Pas in 4.1 wordt MySQL een beetje volwassen. Maarja, MySQL is al met 5 bezig, het zal dus nog wel een jaartje duren voordat 4.1 (die ook alweer heel lang in alpha zit) in beta komt.

MySQL heeft een historie van verkeerde prioriteiten, en dat zie je hier ook weer. Ze gooien zich op clustering, terwijl ze nog niet klaar zijn met consistency controle. Ze hebben de meest elementaire database functies nog niet voor elkaar en dromen al van concurreren met Oracle.

PostgreSQL heeft dat allemaal wel onder de knie, PostgreSQL _is_ een concurrent voor Oracle, het is alleen niet zo bekent als MySQL. Waarom is MySQL wel bekent en PostgreSQL niet? Marketing, that's all.


Tot nu toe heb ik nog niemand gesproken die van PostgreSQL naar MySQL migreerde omdat MySQL meer kon of beter was. Iedereen die PostgreSQL tegenkomt blijft er bij hangen omdat het gewoon meer functionaliteiten heeft (en gewoon sneller is) en dat scheelt heel veel in je ontwikkelproces.

Nogmaals, als MySQL zich serieus met 4.1 bezig zou houden dan hadden we er een leuke database aan, maar zoals altijd doet MySQL net het verkeerde.

[Femme]

Zolang MySQl 4.1 in alpha is is postgresql veruit superieur aan mysql. Pas in 4.1 wordt MySQL een beetje volwassen.

De belangrijkste verbetering in MySQL 4.1 is de ondersteuning van subqueries en derived tables. Het kan aan mij liggen, maar zo essentieel vind ik die features niet. Met een paar joins kun je een heel eind komen. MySQL 5.0 zal stored procedures toevoegen, wat door velen als een veel wenselijker feature zal worden beschouwd.

Foreign Keys worden door InnoDB ondersteund, evenals transacties, versioning en row level locking. Replication wordt al een paar jaar door MySQL ondersteund en nu is er dus ook support voor clustering. Voor zover ik weet heeft PostgreSQL nog steeds geen ingebouwde (open source) replication.

De performance van MySQL is altijd erg goed geweest. De twee storage engines (MyISAM en InnoDB) bieden betere mogelijkheden om te optimaliseren voor een specifieke toepassing en de query cache scheelt behoorlijk in performance.

MySQL heeft een historie van verkeerde prioriteiten, en dat zie je hier ook weer.

De prioriteiten worden bepaald door de klanten van MySQL. Blijkbaar vroegen die om clustering support.

PostgreSQL heeft dat allemaal wel onder de knie, PostgreSQL _is_ een concurrent voor Oracle, het is alleen niet zo bekent als MySQL.

Zonder replication en native Windows support kun je PostgreSQL moeilijk een concurrent voor Oracle noemen.

Waarom is MySQL wel bekent en PostgreSQL niet? Marketing, that's all.

MySQL doet vrijwel niet aan marketing. Het feit dat MySQL eenvoudig te installeren is, onder vrijwel elk platform draait, goed communiceert met populaire scripttalen zoals PHP en er internationale commerciële support voorhanden is, zal veel hebben bijgedragen aan de enorme populariteit van MySQL. Aangezien MySQL in de toekomst alleen maar beter zal worden (zeker nu features uit SAP DB overgenomen zullen worden) voorspel ik dat PostgreSQL altijd in een kleine niche zal blijven opereren en dat MySQL de dominante open source database zal blijven.

[jb044]

Alleen dat distribute internally is een beetje vaag. De gemiddelde hoster zal een server upgrade met zorg zelf samenstellen, tenminste dat hoop ik. En heeft ongetwijfeld een klein leger aan servertjes te upgraden. Kortom interne distributie. Maar iets zegt me dat de gemiddelde hoster weer niet betaald voor mysql.

Maar eerlijk gezegt ken ik geen voorbeelden van mysql.com die hun licentie zo letterlijk neemt. Wel van een (kleine) bijstelling door externe druk (php).

Zie het eerder als een van die opensource bedrijven die ook commercieel closed source gebruik mogelijk maken. Een doorn in het oog van opensource puristen mischien maar ik noem het visie. Dit maakt MySQL juist alleen maar interessanter voor het bedrijfsleven, zeker als je je bedenkt dat niks zo luceratief is als database software.

[ACM]

De belangrijkste verbetering in MySQL 4.1 is de ondersteuning van subqueries en derived tables. Het kan aan mij liggen, maar zo essentieel vind ik die features niet. Met een paar joins kun je een heel eind komen. MySQL 5.0 zal stored procedures toevoegen, wat door velen als een veel wenselijker feature zal worden beschouwd.

Precies, dus eigenlijk wordt MySQL pas vanaf versie 5.0 een geduchte concurrent voor PostgreSQL
Maar die heeft tegen die tijd ook wel een (multi-master) clustering oplossing en native windows support...

Foreign Keys worden door InnoDB ondersteund, evenals transacties, versioning en row level locking.

Versioning en row level locking zijn geen features, maar middelen om andere features bruikbaar te maken. De foreign key implementatie mist nog wel een paar details om het in mijn ogen echt een goede te kunnen noemen.

Replication wordt al een paar jaar door MySQL ondersteund en nu is er dus ook support voor clustering. Voor zover ik weet heeft PostgreSQL nog steeds geen ingebouwde (open source) replication.

Ik meende dat jij de gene was die uitgelegd had aan ons waarom de replication van mysql niet zo lekker werkt
Dat het er al een paar jaar inzit zegt nog niet dat het ook goed werkt.
PostgreSQL heeft inderdaad nog steeds replication op de todo staan en dat komt waarschijnlijk (weer) niet in de eerstvolgende versie, maar het gaat gestaag door en is dan waarschijnlijk wel een stukje flexibeler dan de mysql-manier.

De performance van MySQL is altijd erg goed geweest. De twee storage engines (MyISAM en InnoDB) bieden betere mogelijkheden om te optimaliseren voor een specifieke toepassing en de query cache scheelt behoorlijk in performance.

MySQL heeft een hele simpele/simplistische "optimiser", opzich niet erg, maar moeilijke queries (waar mysql ook niet echt voor bedoeld was) worden nog steeds niet bijster efficient uitgevoerd. 't Gros van de webapplicaties heeft zulke queries ook niet nodig, dus een groot gemis is het nog niet.

Zonder replication en native Windows support kun je PostgreSQL moeilijk een concurrent voor Oracle noemen.

Waarom is het dan ineens moeilijk? Als je zulk soort rare statements maakt, dan is mysql ook totaal geen concurrent voor Oracle...
't Zijn wel degelijk concurrenten van elkaar (ondanks dat men vaak beweert van niet), simpelweg omdat ze allemaal RDBMS-en zijn, weliswaar met verschillende ontwikkelprioriteiten en ontwikkelteams (en dus prijzen). Maar het zijn wel degelijk concurrenten.

MySQL doet vrijwel niet aan marketing. Het feit dat MySQL eenvoudig te installeren is, onder vrijwel elk platform draait, goed communiceert met populaire scripttalen zoals PHP en er internationale commerciële support voorhanden is, zal veel hebben bijgedragen aan de enorme populariteit van MySQL.

MySQL had inderdaad een redelijk handige start, mede (of vooral?) doordat het meelifte op het succes van PHP (dat standaard MySQL-bindings meeleverde). Ik meen trouwens dat MySQL wel degelijk aan marketing doet, PostgreSQL doet vrijwel niet aan marketing.

Aangezien MySQL in de toekomst alleen maar beter zal worden (zeker nu features uit SAP DB overgenomen zullen worden) voorspel ik dat PostgreSQL altijd in een kleine niche zal blijven opereren en dat MySQL de dominante open source database zal blijven.

Ik ben bang dat je wel gelijk hebt, maar het blijft dominant op een vhs vs betamax/video2000 manier, niet omdat het beter is dan de rest, maar omdat het bekender is.

[nightlight]

En als reactie hierop wijk je uit naar PostgreSQL (onder de flexibele BSD licentie, en heeft nog boordevol meer features dan MySQL http://www.postgresql.org ).

[Verwijderd]

t'ja en er is ook nog www.sapdb.org

En aangezien dat MAXDB nu een samengaan is van MySQL met SAP zal dat wellicht aan de grond liggen van hun hoogmoed...

[Verwijderd]

Vooraf, dit komt erg anti-MySQL over, maar let op dat ik hier niets zonder reden zeg. Ik zit niet gewoon MySQL af te zeiken omdat ik MySQL toevallig niet leuk vind. Ik heb lang met meerdere databases gewerkt en dan merk je vanzelf dat MySQL het gewoon niet trekt tegen PostgreSQL, laat staan tegen orable, Informix etc.


"Het kan aan mij liggen, maar zo essentieel vind ik die features niet."

Dat is ook precies wat MySQL jou via de marketing wil laten geloven. Net als dat overhead verhaal. Volgens MySQL's marketing is alles wat ze niet hebben er uit gehaald omdat het de boel alleen vertraagde. Als je gaat zoeken naar de problemen die mensen met MySQL ondervinden dan komen die voor 99% door ontbrekende functionaliteit die andere databases wel hebben.

- MySQL ondersteund zelf nog geen transactions en PK/FK. InnoDB doet dat, en InnoDB is niet van MySQL.
- PostgreSQL heeft wel replicatie, maar heeft het veel minder nodig omdat het onder hoge belasting beter presteert dan MySQL. MySQL repliceert hoofdzakelijk om loadbalancing te kunnen doen.


"De twee storage engines (MyISAM en InnoDB) bieden betere mogelijkheden om te optimaliseren voor een specifieke toepassing"

Heb je wel eens gekeken naar de opties die er zijn bij MySQL en wat er is bij bv PostgreSQL? Dat is even schrikken.


"de query cache scheelt behoorlijk in performance."

Dat valt heel erg mee, de query cache scheelt alleen als de data waar de query over gaat niet is verandert sinds de vorige query. En hoe vaak komt dat voor, vooral in een druke database?


"De prioriteiten worden bepaald door de klanten van MySQL. Blijkbaar vroegen die om clustering support."

Was dat maar waar!
De klanten schreeuwen al jaren om transactions, subqueries en stored procedures, omdat dat gewoon broodnodig is.
In plaats daarvan gaan ze clustering ontwikkelen, iets wat maar voor een heel erg klein deel van de klanten interessant is.

Ik snap het ook wel, want die klanten die clustering nodig hebben zullen flink investeren in support contracten en daar verdient MySQL aan, niet aan nozempjes die MySQL gebruiken voor hun website.


"Zonder replication en native Windows support kun je PostgreSQL moeilijk een concurrent voor Oracle noemen."

Replication heeft PostgreSQL dus wel, maar waar denk je dat de grote bedrijven Oracle op draaien? Niet op windows.
Dat je MySQL op windows kunt draaien heeft precies 1 voordeel; elke jandoedel kan het thuis installeren. In productie omgevingen telt dat helemaal niet want
niemand zal het in zijn hoofd halen om een database op windows te draaien als het ook op linux/unix kan.


"MySQL doet vrijwel niet aan marketing."

Hallo, waar heb jij de afgelopen jaren gezeten? MySQL doet heel veel aan dan merketing. PostgreSQL doet weinig aan marketing, daarom zijn ze relatief onbekend bij de grote massa.


"Het feit dat MySQL eenvoudig te installeren is, onder vrijwel elk platform draait, goed communiceert met populaire scripttalen zoals PHP en er internationale commerciële support voorhanden is, zal veel hebben bijgedragen aan de enorme populariteit van MySQL."

Nu noem je precies de dingen die de marketing je "wijsmaakt". Op oracle en informix na zijn alle databases makkelijk te installeren, ze praten allemaal met elke programmeertaal en er is overal commerciele support voor te vinden.


"Aangezien MySQL in de toekomst alleen maar beter zal worden (zeker nu features uit SAP DB overgenomen zullen worden) voorspel ik dat PostgreSQL altijd in een kleine niche zal blijven opereren en dat MySQL de dominante open source database zal blijven."

Ik heb er een hard hoofd in. SAP is nu ook niet echt geweldig, en van de plannen van MySQL komt tot nu toe niet veel terecht. (4.1 is al heel erg lang in alpha, en nu is zelfs 5 al in alhpa vrijgegeven. Dat is toch bizar?)

[Femme]

Dat is ook precies wat MySQL jou via de marketing wil laten geloven.

Ik kan zelf wel bepalen dat het gemis van subqueries voor mij geen probleem is. Als je zonodig subqueries en stored procedures wilt gebruiken moet je maar een andere database pakken. Vaak kun je er ook gewoon omheen programmeren, maar ik krijg de indruk dat sommige personen daar een onnodig groot probleem van maken.

MySQL ondersteund zelf nog geen transactions en PK/FK. InnoDB doet dat, en InnoDB is niet van MySQL.

InnoDB is al enige tijd een standaard onderdeel van MySQL.

PostgreSQL heeft wel replicatie, maar heeft het veel minder nodig omdat het onder hoge belasting beter presteert dan MySQL.

Voor zover ik heb begrepen moet je voor replicatie (vaak commerciële) third-party add-ons gebruiken. MySQL presteert trouwens uitstekend onder hoge loads als je de InnoDB storage engine gebruikt (met row-level locking). MyISAM tabellen doen het ook prima onder een hoge load zolang er niet veel mutaties van de database zijn.

Dat valt heel erg mee, de query cache scheelt alleen als de data waar de query over gaat niet is verandert sinds de vorige query. En hoe vaak komt dat voor, vooral in een druke database?

In onze database helpt het behoorlijk.

De klanten schreeuwen al jaren om transactions, subqueries en stored procedures, omdat dat gewoon broodnodig is. In plaats daarvan gaan ze clustering ontwikkelen, iets wat maar voor een heel erg klein deel van de klanten interessant is.

Transacties zitten al jaren in MySQL, via InnoDB. Als er echt veel klanten (betalende gebruikers) naar stored procedures zouden vragen, zou er wel meer prioriteit aan gegeven worden. Het is goed denkbaar dat de klanten van MySQL een vergelijkbare mentaliteit ten aanzien van stored procedures hebben als MySQL zelf, namelijk dat je de functionaliteit ook grotendeels in eigen software kunt oplossen. Dit is anders bij clustering.

"Die nozempjes die MySQL gebruiken voor een website" zijn geen klant maar een niet-betalende gebruiker. Het is logisch dat MySQL voorrang geeft aan de wensen van betalende gebruikers.

Replication heeft PostgreSQL dus wel, maar waar denk je dat de grote bedrijven Oracle op draaien? Niet op windows.

Waar het om gaat is dat PostgreSQL (net zoals MySQL trouwens) nog features en support mist om met de grote spelers mee te doen in het high-end segment. Ik zie MySQL die barrière eerder slechten dan PostgreSQL vanwege de betere ondersteuning en naamsbekendheid, en de ontwikkeling van nu nog ontbrekende features zoals subselects en stored procedures. Ondanks het ontbreken daarvan heeft MySQL nu al een veel betere acceptatie in grote bedrijven.

In productie omgevingen telt dat helemaal niet want niemand zal het in zijn hoofd halen om een database op windows te draaien als het ook op linux/unix kan.

Toch zijn er bedrijven die vinden dat Windows een betere oplossing voor hen is.

Hallo, waar heb jij de afgelopen jaren gezeten? MySQL doet heel veel aan dan merketing. PostgreSQL doet weinig aan marketing, daarom zijn ze relatief onbekend bij de grote massa.

Wat doet MySQL volgens jou dan aan marketing? Ze bezoeken wat beurzen en organiseren een developers conferentie. Adverteren doen ze niet. Het verlenen van commerciële support en het organiseren van trainingen voor developers en systeembeheerders is geen marketing maar gewoon dienstverlening.

Nu noem je precies de dingen die de marketing je "wijsmaakt". Op oracle en informix na zijn alle databases makkelijk te installeren, ze praten allemaal met elke programmeertaal en er is overal commerciele support voor te vinden.

Het niet alleen om de installatieprocedure maar ook om het beheren van users en het optimaliseren van de server. Dat is bij MySQL allemaal erg eenvoudig en relatief goed gedocumenteerd, en er is veel kennis bij andere gebruikers. De commerciële support (direct van de maker, zoals de meeste bedrijven dat het liefst zien) is bij MySQL zonder twijfel beter geregeld dan bij PostgreSQL.

Ik heb er een hard hoofd in. SAP is nu ook niet echt geweldig, en van de plannen van MySQL komt tot nu toe niet veel terecht. (4.1 is al heel erg lang in alpha, en nu is zelfs 5 al in alhpa vrijgegeven. Dat is toch bizar?)

Het zal een kwestie van prioriteiten zijn. Nu clustering af is komt er wellicht weer wat meer vaart in de ontwikkeling van 4.1. Dat MySQL 5 nu al als development preview is vrijgegeven is alleen maar handig voor mensen die nieuwe features willen uitproberen.

[Femme]

Ik meende dat jij de gene was die uitgelegd had aan ons waarom de replication van mysql niet zo lekker werkt
Dat het er al een paar jaar inzit zegt nog niet dat het ook goed werkt.

Dat was bijna drie jaar geleden. Je mag aannemen dat replication inmiddels betrouwbaar werkt, ook gezien het grote aantal bugfixes mbt replicatie die er sindsdien zijn geweest.

Waarom is het dan ineens moeilijk? Als je zulk soort rare statements maakt, dan is mysql ook totaal geen concurrent voor Oracle... 't Zijn wel degelijk concurrenten van elkaar (ondanks dat men vaak beweert van niet), simpelweg omdat ze allemaal RDBMS-en zijn, weliswaar met verschillende ontwikkelprioriteiten en ontwikkelteams (en dus prijzen). Maar het zijn wel degelijk concurrenten.

Je hebt gelijk dat ze allemaal een concurrent van elkaar zijn, alleen op verschillende niveau's. Als webdatabase kan MySQL zich prima meten met Oracle en is het mogelijk een betere oplossing (ook als je niet naar prijs zou kijken). Op andere gebieden doet MySQL onder voor Oracle. PostgreSQL is mijn inziens nog niet zo ver gevorder dat het in alle segmenten kan concurreren met Oracle.

MySQL kan hier op de lange termijn best succesvol zijn omdat hun businessmodel goed aansluit op de wensen van commerciële gebruikers.

Ik ben bang dat je wel gelijk hebt, maar het blijft dominant op een vhs vs betamax/video2000 manier, niet omdat het beter is dan de rest, maar omdat het bekender is.

Nog een paar jaar en dan heeft MySQL een featureset van enterpriseniveau. Er blijft dan nog weinig te klagen over.

[berend_engelbrecht]

Het enige wat wij in de huidige MySQL missen is subqueries. Foreign keys (automatisch de relaties tussen de verschillende tabellen verprutsen), stored procedures (een vendor-specifiek script taaltje - alles 3x implementeren, nee dank u) en transacties (lekker langzaam, in sommige engines niet AF te zetten) hebben we nooit echt nodig gehad in onze web-applicaties

[Verwijderd]

"Foreign keys (automatisch de relaties tussen de verschillende tabellen verprutsen), stored procedures (een vendor-specifiek script taaltje - alles 3x implementeren, nee dank u) en transacties (lekker langzaam, in sommige engines niet AF te zetten) hebben we nooit echt nodig gehad in onze web-applicaties"

Dit is gewoon flamebait. Als dit jouw echte mening is dan heb je geen ervaring met databases of je snapt er echt helemaal niets van.

[Verwijderd]

"Als je zonodig subqueries en stored procedures wilt gebruiken moet je maar een andere database pakken."

Wat is dat nu voor een fatalistisch argument? Als jij zo'n mooie JOIN zit te tikken die er vervolgens 3 seconden over doet om te draaien, heb jij dan nooit zoiets van "verdomme waarom doet MySQL niet gewoon subqueries, dan was ik zo klaar"? Jij gaat gewoon lekker zitte kloppen en accepteert dat het nu eenmaal zo is?


"Vaak kun je er ook gewoon omheen programmeren, maar ik krijg de indruk dat sommige personen daar een onnodig groot probleem van maken."

ARG! Hier kan ik echt slecht tegen
Je gaat toch niet database functionaliteit in je applicatie zitten bouwen? Dat is toch gekkenwerk man. Je gaat toch je applicatie niet ingewikkelder maken omdat de database die je gebruikt iets niet kan terwijl vrijwel alle andere databases het wel kunnen? Dan ga je toch op zoek naar een betere database?


"InnoDB is al enige tijd een standaard onderdeel van MySQL."

Het wordt standaard meegeleverd, omdat zoveel klanten vroegen hoe ze InnoDB moesten installeren. Het wordt nog niet standaard gebruikt.

"Voor zover ik heb begrepen moet je voor replicatie (vaak commerciële) third-party add-ons gebruiken."

Ik vertel je dus net dat dat niet zo is.

"MySQL presteert trouwens uitstekend onder hoge loads als je de InnoDB storage engine gebruikt (met row-level locking). MyISAM tabellen doen het ook prima onder een hoge load zolang er niet veel mutaties van de database zijn."

Dit wordt een wellis niettes verhaal. Mijn ervaring met MySQL is dat het breekt onder hoge belasting. Jouw ervaring is, gelukkig voor jou, anders.


"In onze database helpt het behoorlijk."

hehe, in onze database schelen de stored-procedures, functions, triggers, partial-indexes, functional indexes en subqueries nog veel meer, niet alleen in snelheid, maar ook in ontwikkeltijd. Onze databases hebben nooit orphan records, hoe debiel de programmeur ook tekeer gaat.


"Als er echt veel klanten (betalende gebruikers) naar stored procedures zouden vragen, zou er wel meer prioriteit aan gegeven worden."

Was dat maar waar, luisterde MySQL maar naar haar klanten. MySQL heeft er gewoon geen zin in of geen resources voor. MySQL stelt nu eenmaal vreemde prioriteiten, zoals snelheid. MySQL heeft in MyISAM de PK/FK relaties er aan gegeven omdat het sneller is zonder. Dat daarmee je database een onsamenhangende brij kan worden dat boeit blijkbaar niemand.

"Het is goed denkbaar dat de klanten van MySQL een vergelijkbare mentaliteit ten aanzien van stored procedures hebben als MySQL zelf,
namelijk dat je de functionaliteit ook grotendeels in eigen software kunt oplossen."

Ik hoop echt dat dat niet het geval is. Als de grote massa die MySQL gebruikt echt zo denkt dan is het diep triest gesteld met de wereld.


"Waar het om gaat is dat PostgreSQL (net zoals MySQL trouwens) nog features en support mist om met de grote spelers mee te doen in het high-end segment."

PostgreSQL kun je nog net niet als een drop-in replacement voor Oracle gebruiken, maar het zit er heel erg veel dichter bij dan MySQL.
MySQL is veel en veel te vergevend om ooit Oracle te kunnen concurreren. Oracle is erg strict en zal koste wat kost voorkomen dat jij foute data in je database stopt. MySQL helpt je graag bij het invoeren van foute data.


"Ondanks het ontbreken daarvan heeft MySQL nu al een veel betere acceptatie in grote bedrijven."

Moet je wel onthouden dat de enige reden dat MySQL wordt geaccepteert is dat iedereen wel eens van MySQL heeft gehoord. Elke werknemer draait het thuis en kan ermee overweg en dus "is het een goed product".
Als je de features van MySQL vergelijkt met PostgreSQL (of interbase of sybase) dan schuif je MySQL echt lachend opzij als een hopeloos onbruikbaar speledingetje.


"Toch zijn er bedrijven die vinden dat Windows een betere oplossing voor hen is."

Er zijn altijd uitzonderingen, maar denk je dat MySQL zijn populariteit te danken heeft aan een handjevol bedrijven die perse windows willen draaien?


"Adverteren doen ze niet."

Ah, dan zullen die banners op tweakers en PFZ wel illusie zijn geweest.


"maar ook om het beheren van users en het optimaliseren van de server. Dat is bij MySQL allemaal erg eenvoudig en relatief goed gedocumenteerd,"

Net als bij _elke_ andere database.


"en er is veel kennis bij andere gebruikers."

Net als bij _elke_ andere database.


"De commerciële support (direct van de maker, zoals de meeste bedrijven dat het liefst zien) is bij MySQL zonder twijfel beter geregeld dan bij PostgreSQL."

Klopt, PostgreSQL is niet commercieel, je kunt geen supportcontract afsluiten met de makers, maar wel met 3d parties.


"Het zal een kwestie van prioriteiten zijn. Nu clustering af is komt er wellicht weer wat meer vaart in de ontwikkeling van 4.1."

Denk je? Ik denk eerder dat ze na introductie van clustering een hele hoop herrie krijgen van de nieuwe cluster-gebruikers over het ontbreken van al die elemantaire zaken zoals triggers en dat ze 4.1 dan gewoon stoppen en doorgaan met 5. Dat geeft ze weer een paar jaar de tijd om al die elementaire dingen door te voeren.


"Dat MySQL 5 nu al als development preview is vrijgegeven is alleen maar handig voor mensen die nieuwe features willen uitproberen."

Het is een alpha, dat geef je niet vrij. Beta's geef je vrij omdat die semi-stabiel zijn. Alpha's houd je voor jezelf want die kunnen de broel nog behoorlijk laten crashen.


MySQL moet snel volwassen worden want ze proberen steeds verder in de professionele tak door te dringen en ze komen steeds dichter bij de mensen die wel weten wat databases zijn en wat databases horen te kunnen. En de huidige MySQL versies voldoen dan gewoon niet. Geen enkele ervaren database gebruiker zal bv accepteren dat hij zelf in zijn applicatie moet gaan voorkomen dat er te lange waardes in een kolom komen. Elke ervaren database gebruiker wil subqueries, triggers, functions, en de grote database gebruikers (honderden miljoenen records) die willen echt perse functional indexes en partial indexes, anders duren hun queries weken ipv dagen.

[klokop]

Heeft T.net ook een licentie voor MySQL eigelijk? Of doen we het hier met de gratis versie?

[Femme]

Tweakers.net heeft geen commerciële MySQL-licentie.

[Verwijderd]

Gaat tweakers.net over op MAXDB? nu dat MySQL SAP DB heeft overgenomen?

[Femme]

Nee, we blijven gewoon MySQL draaien. Ik denk wel dat uiteindelijk bijna alles op de InnoDB storage engine gaat draaien.

[Verwijderd]

Dat zal met de afmeting van de datafiles ook wel nodig zijn denk? Met InnoDB kun je de datafiles fragmenteren over meerdere disks, dat scheelt nogal in snelheid.

[Q-collective]

Tweakers.net BV is een commercieel bedrijf...

[Verwijderd]

je kan wel zien dat jullie de gratis no-support versie gebruiken (www.r3diensten.nl)

Portfolio links doen het niet, en als ik op klanten click, krijg ik de melding...Template error: Could not connect to database...amateurs...

[Verwijderd]

LOL!!@omixium jij bent echt een etter om die jongen zo te pesten en public!! Maar je hebt gelijk...

Maar waarom MySQL gebruiken? Ik heb de ervaring dat het onstabiel is en tevens memory leaks van hier tot aan de keukendeur ...

Afijn, wellicht met de betaalde versie lukt het allemaal maar ondertussen heb ik meer pret met Postgres/RedhatDB. Ik heb zo een vermoeden dat Postgres een grotere rol zal gaan spelen, zeker gezien het feit dat het 'echte' open source is en daardoor de volledige support krijgt van OSS gigant Redhat.

[Verwijderd]

Wat dacht je van licentie's voor bedrijven?

Net zoiets als Red Hat Enterprise, je betaalt en je krijgt ook support enzoz. Je hebt ook een gratis versie van Red Hat, daar zit geen support etc bij.

Zoiets moet je aan denken

[RSpliet]

Men die niet MySQL gebruikt, gebruikt iig. nog PostgreSQL... MSSQL is simpelweg te duur voor huis-tuin-en-keukenscripters, en MySQL presteert zeer goed (kan t niet vergelijken met MSSQL, maar zal wel dicht in de buurt komen ). Daarnaast weet ik niet hoe het met MSSQL zit, maar als dit net zoals Jet geen LIMIT ondersteunt, zit ik er niet op te wachten (die vage TOP-constructies lijken nergens naar als je t mij vraagt)

Edit (mierenneukmodus): het is geen freeware product, het is open-source. Dat zijn 2 hele verschillende licentietypen .

[Crazy D]

Grappig dat "men" altijd zo klaagt over Microsoft, dat die standaarden aanpast voor eigen gebruik. MySql doet hetzelfde (LIMIT is geen standaard SQL), maar dan is het wel goed?

[Crazy D]

Uiteraard heeft iedere leverancier z'n eigen dialect, maar een opmerking als "Daarnaast weet ik niet hoe het met MSSQL zit, maar als dit net zoals Jet geen LIMIT ondersteunt, zit ik er niet op te wachten (die vage TOP-constructies lijken nergens naar als je t mij vraagt)" vind ik net zo typerend als iemand die zegt "dat z'n website het toch doet in Internet Explorer".

Maar zo serieus bedoelde ik het niet (ik zou LIMIT ook een handige aanvulling vinden in MSSQL ) 't viel me gewoon op. Er (en zeker hier) wordt altijd lekker veel gezeken op MS die zich niet aan standaarden zou houden, en dan hier iemand die LIMIT als reden noemt om MySql te prefereren, iets wat juist niet-standaard SQL is...

[raptorix]

ANSI-92 werkt anders prima op MSSQL, iets wat bij mysql nauwelijks in de buurt komt, daarnaast bestaat er wel degelijk een limit functie in MSSQL namelijk ROWCOUNT, werkt prima, overigens is er een groot verschil tussen ROWCOUNT en TOP, ROWCOUNT geeft onmiddelijk resultaat terug wanneer er x records zijn gevonden, bij TOP wordt dus de complete query uitgevoert en slechts een gedeelte terug gestuurt naar de client.

Overigens zitten er wel wat vieze dingen in t-sql, met name de Cross join is erg raar, maarjah zo heb je dat vrijwel in elke grote DB.

[spoonman]

reactie op sjors:

Ik denk dat hij het hier over paging heeft, en niet gewoon het aantal records beperken. T-Sql mist wel enkele features om paging eenvoudiger te maken

Oracle had daar een mooie oplossing voor dacht ik, en als ik me niet vergis MySql ook door bvb LIMIT 50, 100 achter je query te plakken (correct me if i'm wrong)

[Verwijderd]

nog een reactie op sjors,
ROWCOUNT zou ik niet gebruiken ipv limit/top dit is nl een 'globale' instelling, behalve natuurlijk als je wilt dat alle query's het zelfde aantal records teruggeven.

[Verwijderd]

Microsoft maakt misbruik van haar monopoliepositie op de desktop en in office toepassingen. MySQL heeft alles behalve een monopoliepositie.

'standaard SQL' is een utopie; iedere leverancier heeft zijn eigen dialect. Wel eens een lege string weggeschreven in Oracle? Als je het weer inleest krijg je een null string terug; niet echt standaard te noemen.

[berend_engelbrecht]

@spoonman

Oracle had daar een mooie oplossing voor dacht ik, en als ik me niet vergis MySql ook door bvb LIMIT 50, 100 achter je query te plakken (correct me if i'm wrong)

Je verhaal over LIMIT klopt, maar wat is de mooie oplossing van Oracle dan, die zou ik graag kennen? Voor zover ik weet heeft het noch LIMIT, noch TOP. Je kan iets met ROWID doen, maar daar ga je al snel de mist in als je sorteert op een andere volgorde dan de key die je gebruikt in je WHERE conditie.

Een goede paging-constructie voor Oracle zou heel welkom zijn, het ontbreken daarvan is de voornaamste reden waarom Oracle bij grote paged-recordset zoveel beroerder presteert (op dezelfde hardware) dan MS SQL of MySQL in onze metingen.

(sorry als mensen dit off-topic vinden, maar dit is al heel lang een probleem voor me)

[curry684]

Men die niet MySQL gebruikt, gebruikt iig. nog PostgreSQL... MSSQL is simpelweg te duur voor huis-tuin-en-keukenscripters.

Oh? De Microsoft SQL Server Desktop Engine is anders ook 100% gratis te downloaden vanaf www.microsoft.com/sql/msde en bevat de volledige SQL Server engine. Mijn eigen webservertje thuis draait WinXP Pro, MSDE, PHP en Apache: een volgens veel mensen vreemde combo maar wel rocksolid, snel, flexibel en betrouwbaar.

Niet iedereen over 1 kam scheren omdat jij zelf toevallig 1 specifieke combinatie gebruikt

[Verwijderd]

Bij een echte programmeur maakt het niet uit wat voor Model" je er onder stopt Maar MySQL is een leuk Model om mee te spelen.

[Verwijderd]

"Bij een echte programmeur maakt het niet uit wat voor Model" je er onder stopt"

Je bedoelt; bij een masochistische programmeur die tijd teveel heeft :-)

Negen van de tien database-functies die je bij MySQL in je programma moet uitvoeren kun je bij elke andere database gewoon doen waar het hoort: in de database.

Daar laat MySQL steekjes vallen. MySQL pocht snel en makkelijk te zijn, maar het komt er op neer dat ze gewoon een minimalistische database hebben gebouwd en een database die weinig kan die moet wel snel zijn.

[Verwijderd]

Wie van onze PHP scripters gebruikt MySQL nou niet?

Ik
Hier draait PostgreSQL

[Defspace]

+1 Inzichtvol
Maar ja.. Laten we er geen PostgreSQL vs MySQL flamethread van maken... Is zo lullig voor die MySQL aanhangers
Nah.. MySQL doet het ook best aardig de laatste tijd.
Toch geniet PostgreSQL wat mij betreft zakelijk altijd de voorkeur...

[Verwijderd]

Ik vind MySQL nog een aantal beperkingen hebben. Zoals het niet ondersteunen van subqueries e.d., iets wat toch zeer praktisch kan zijn ?

Ok, dit valt allemaal op te vangen, maar hoe zit het dan met performance ...

[Verwijderd]

Vanaf MySQL 4.1 worden subqueries ondersteund...
http://dev.mysql.com/doc/mysql/en/Subqueries.html

[Verwijderd]

Helaas is dat nog in alpha, al een jaar ofzo?

[klokop]

die zijn toch vrijwel altijd wel te omzeilen met een fijne join?

[KinkyClown]

Zoals, jeroenr al zegt, deze zitten er nu wel in vanaf versie 4 maar wat ik wel weer mis (en dat schijnt pas weer te komen in versie 5) zijn stored procedures en functions.

[Left]

Wat ik nou niet snap is dat MySQL zoveel populairder is dan PostgreSQL. Want die laatste is imo toch een veel betere database

[Verwijderd]

beter betekent binnen de IT niks. Je prestaties kunnen in een pakket de beste zijn, maar als er iets anders los zit zal dat het wl zijn. Denk dat het hier iets met de schaalbaarheid en gebruiksgemak te maken zal hebben.

[napel25]

Dat ligt, denk ik, aan dat programmeurs vaak kiezen welke database wordt gebruikt. MySQL is een echte programmeurs database omdat het met de standaard instellingen een 'hoog emmer gehalte' heeft. Met een 'hoog emmer gehalte' bedoel ik dat je er alleen data in kan doen er er weer uit kan halen. Alle data rules worden verder liever in de applicatie gebouwd.
De ACID eigenschappen die een database hoort te hebben en het feit dat een database met rules qua beheer makkelijker overdraagbaar is als een custom applicatie wordt door programmeurs vaak vergeten. (geen beschuldiging, want dat is simpel weg hun probleem niet)
Als je een emmer zoekt, is MySQL verreweg de beste oplossing.

[mxcreep]

Wat dacht je van dat de drempel om MySQL te gebruiken lager ligt voor mindere script goden en hobbyisten...die willen een auto increment field in plaats van zelf een trigger aan moeten maken en meer van dat soort dingen...

Doordat MySQL minder mogelijkheden heeft is het in situaties waar hij voldoet ook erg snel en makkelijk implementeren...

[macnerd]

Lol, ik wilde een tijdje geleden voor commercieel gebruik zo'n mysql sever gebruiken, dat is ook echt niet gratis hoor.

(thegve)

Klopt, maar alleen als je je applicatie closed wil houden. Als je je applicatie open source (gpl) maakt mag je het ook voor commerciele doeleinden gebruiken.

[Priet]

Dus stel ik maak een website in PHP die gebruik maakt van MySQL en ik 'verkoop' die website aan een of meerdere klanten dan hoef ik niet te betalen voor het gebruik van MySQL in de site?

[Verwijderd]

Dan moet jeh te wat "linker " aanpakker... je maakt een website en maakt die opensource. Je laat je klant eenmalig een "head support (dus eigenlijk het bedrag dat je wil hebben voor de website)" bedrag betalen en daarna elke keer als je de boel een beetje bijwerkt.

+ 1 duivels

[joco]

Wat een onzin dat je voor closed source apps voor mysql zou moeten betalen..

Zolang je maar een andere database er onder kunt drukken, dus niet puur alleen op mysql depend en niet tegen mysql aan compileerd (linked) dan kun je mysql prima gebruiken.

bv als je een commercieel pakket hebt en je shipped dat naar een klant. Dan mag je mysql niet mee shippen maar je moet tegen de klant zeggen dat hij daar mysql vandaan kan halen en dat hij die zelf eerst moet installeren..

Voor websites die java als backend gebruiken is dit prima te doen want je linked/compileerd niet tegen mysql of hun drivers.. Ze moeten dan alleen de driver in de appserver hangen en de database installeren..

[Verwijderd]

bv als je een commercieel pakket hebt en je shipped dat naar een klant. Dan mag je mysql niet mee shippen maar je moet tegen de klant zeggen dat hij daar mysql vandaan kan halen en dat hij die zelf eerst moet installeren..

Van MySQL.com:

When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to distribute MySQL software (be that externally to customers or internally within your organization), you must first obtain a commercial license to the MySQL product.

Typical examples of MySQL distribution include:

Selling software that includes MySQL to customers who install the software on their own machines.

Selling software that requires customers to install MySQL themselves on their own machines.

Building a hardware system that includes MySQL and selling that hardware system to customers for installation at their own locations.

Meer info op :

http://www.mysql.com/products/licensing/commercial-license.html

[joco]

ik zei ook mysql moet niet de enige optie zijn..

En dat is dus nooit zo.. Het is geen requirement om mysql te gebruiken het mag.. DAt is nu net het makkelijke als je drop in jdbc drivers gebruikt met bv hibernate (de persistentie laag)..

Dus je moet je web applicatie gewoon schrijven dat hij mysql KAN gebruiken maar niet MOET gebruiken.
Dan is mysql echt gewoon gratis. Want GPL schrijft dat gewoon voor. Zolang je het niet veranderd of tegen aan compileerd/linked zit je goed.

Zij misbruiken eigenlijk GPL compleet trouwens

[SED]

Zo is dat , als je de zelf bedachte toepassing schenkt aan de wereld doe je mee..
Anders moet je bloeden..

[Verwijderd]

Beetje tegenstrijdig:

1. Ze vullen een low end gat.
2. Ze gaan een cluster versie introduceren om grote bedrijven te intereseren.

Ik zal wel gek wezen, maar dat noem ik toch echt geen low end gat op proberen te vullen.

[Verwijderd]

Ze stappen dus in het Low-end gat, en veroveren van daaruit de high-end markt, precies zoals MS het met SQL-server gedaan heeft cq. aan het proberen is.

[Verwijderd]

Clusteren in de low end markt is een groot gat in de markt. Uptime is niet alleen voor een groot bedrijf weggelegt, zeker bij kleine bedrijven die geen eigen systeembeheerder hebben is uptime erg belangrijk.

Hardware gaat tegenwoordig voor een grijpstuiver weg, waarom zou je dan niet gaan clusteren.

[EfBe]

Low end is 1 servertje met alles erop. Als je een cluster neerzet heb je geen low-end oplossing meer.

[klakkie.57th]

Waarom denk je dat ieder bedrijfje zomaar zijn hardware bij de Aldi haalt ??
Een degelijk server kost best wel nog wat duiten hoor. Gemiddelde HP server met een beetje functionaliteiten als dual voeding, raid 5 scsi en SDLT kost toch al gauw 15000 E

[Hans1990]

Maar vergeet niet, als je de mensen hun vertrouwen wint in de wat kleinere dingetje's. Zoals kleinere website's, en die persoon gaat een grotere (commerciele) website van maken klimmen ze vanzelf op naar "high end", maar dat kan wel een hele tijd duren en niet iedereen gaat opeens een grote website maken. Tevens kan die persoon ook nog andere mensen MySQL aanleren om te gebruiken of het als tip te geven.

Dus zo slecht is low end niet eens, het word al vaak gebruikt. Alhoewel MySQL wel wat begint achter te lopen op features vind ik, Subqueries komen er wel in (die zitten erin, in V4.1. Maar die is nog beta, alhoewel ik die al wel draai ).

[Tjeerd]

Ik hoor en zie om me heen wel waarvoor grote bedrijvendatabases als Oracle en MS-SQL worden gebruikt en dat is op zich best om te huilen. Ok, het zal best schaalbaar zijn die grote databases en veel aan kunnen, zonder twijfel. Maar vaak is het overkill, en kun je met een relatief simpele MySQL database ook prima vooruit (zie Tweakers.net).

Ik hoop alleen dat het wel gratis blijft.

[Max|Burn]

Ik heb met een gigantisch project(groep) voor Rabobank Amsterdam een DataWarehouse gebouwd..wil je toch echt niet met MySQL doen...

[Tjeerd]

Daar zijn dus ook de grote databases voor, grote banken hebben daar het geld voor en vaak is het daar ook echt nodig om wat meer uit de kast te halen dan een standaard database.

Maar in veel gevallen kan MySQL wel een oplossing zijn en hoeft er niet direct te worden gegrepen naar een 'grote' database, omdat veel dan die features toch nooit worden gebruikt.

[Verwijderd]

Daar zijn dus ook de grote databases voor,

Wat is groot? MySQL kan echt wel wat hebben hoor, kijk hier maar:

http://www.mysql.com/it-resources/case-studies/

[Verwijderd]

Jij gelooft propaganda?

De verhalen die de maker van een product over het product zelf vertelt moet je nooit geloven, niet van MySQL en niet van de rest.

MySQL kan heel wat hebben in rijen-per-tabel, maar niet qua aantal queries dat tegelijk op die tabel wordt losgelaten.

Met "groot" bedoelen we meestal Oracle en DB2, de jongens die de markt beheersen.

[Verwijderd]

"Jij gelooft propaganda? "

Vaak niet, in dit geval wel

"maar niet qua aantal queries dat tegelijk op die tabel wordt losgelaten."

Slashdot draait ook op MySQL

[Verwijderd]

Je kunt met MySQL zonder meer goede en grote dingen doen, maar je maakt het jezelf wel erg lastig.

Mijn persoonlijk peeve met MySQL is dat ze gewoon ver achterlopen in functionaliteit, en dat goedpraten met de smoes dat je die functionaliteit niet nodig hebt en dat het de boel alleen maar vertraagd.

Helemaal een paar jar geleden, toen row-level locking er nog niet was. Waarom was dat er niet? Volgens MySQL omdat het traag is om per rij te locken. Dat het alternatief table-level locking is waardoor je tabel effectief single-user wordt en dat dat nog heel erg veel trager is, dat zeggen ze er niet bij; table-level locking is erg snel... jaja...

Als je eenmaal gesnoven hebt aan bv triggers en stored procedures, dan zie je dat een groot deel van je scripts ineens veel eenvoudiger zou kunnen. Subqueries scheelt je gewoon een hele hoop in de complexiteit van je query, en daarmee in de snelheid van je query.

MySQL is eenvoudig en presteert ook goed als alles wat je ermee doet maar eenvoudig blijft. Helaas blijft het nooit eenvoudig, je groet altijd uit MySQL, maar ach, dan staat alles al in MySQL en dan ga je maar door.

Helaas komen zo ook MySQL gebruikers in grotere omgevingen waar ze in hun enthausiasme ook MySQL gaan aanraden en gebruiken, en dan gaat het mis.

[maratropa]

Wat ik niet begrijp is dat ze nu pas met een grafische beheer tool komen. had er al vanaf het begin in moeten zitten.

[Verwijderd]

Er was al een tool... "Mysql control center" kon je zelfs vanuit windows de oel grafisch benaderen.

Nee hun eigengemaakt mysql administrator komt binnenkort uit... die zal hier en daar wat beter zijn naar horen zeggen

[Verwijderd]

Waarom zitten mensen in vredesnaam het huidige MS SQL Server en Postgres met mysql te vergelijken..

Het zijn twee totaaal verschillende oplossingen.

Databasese zoals IBM DB2, Oracle 9i en MS SQL Server 2000 kennen een veel hogere overhead. Dit betekent dat met complexe queries (zoals bij een Datawarehouse) deze een snel resultaat opleveren en/of efficient werken, cost based of row based whatever.

een MysQL database engine kent een lage overhead. Dit is prima als web backend. lekker vlot, want die overhead word bij elke query wel aangesproken. een select count(*) op een tabel van 3 miljoen records is eitje voor mysql terwijl Oracle er iets langer over doet.

Een complex join of een subquery op zo'n tabel kan mysql praktisch voor enkele uren lam leggen.
Op zich is het clusteren dan wel weer ok.. voor grote complexe queries kun je toch een grote overhead aanspreken.

Conclusie:
1: Snel resultaat/antwoord op kleine querues ivm lage overhead.
2: Snel resultaat/antwoord op complexe queries met lange runtimes en veel disk I/O vanwege de mogelijkheid van aanspreken van extra overhead op andere nodes.

[Verwijderd]

Wij vergelijken het niet alleen, MySQL vergelijkt zichzelf dolgraag met de grote jongens, om aan te tonen dat ze sneller zijn. Sneller in toepassingen waar de grote jongens niet voor gebrukt worden, maar dat is marketing


MySQL is idd lekker vlot voor websites... in de queries.
MySQL doet niets aan consistency controle, dus al die overhead waar jij het over hebt wordt gewoon verplaatst van de database naar je applicatie. simpel voorbeeld; als je een VARCHAR(100) definiert in MySQL en je stopt er een string van 200 tekens in, dan voorkomt mysql overhead door gewoon de eerste 100 tekens op te slaan en de rest te vergeten. Helaas geeft mysql daar geen melding dan, dus nu moet jij in je script gaan controleren of de string niet te lang is voordat je hem invoert. MySQL snel, je applicatie traag. Vergeet jij die controle, dan is je data nog corrupt ook. Zoek voor de grap eens op "Duplicate entry '127' for key 1" , die krijg je als je 128 wilt invoeren in een PK van type TINYINT. Daar krijg je ook geen melding dat 128 niet past, nee, mysql rond het af op 127 en zeurt dan dat die waarde al bestond.

Het hele "waanidee" is nu juist dat je voor een website geen complexe queries en errorchecks nodig zou hebben. Alsof je in je webwinkel ineens wel kunt leven met afgeronde prijzen omdat je datatype de waarde niet aan kan, of afgekapte adressen omdat het veld te klein was.

Volgens MySQL kon (ze hebben gelukkig hun meningen bijgesteld onder druk van hun klanten) je altijd elke subquery oplossen met een JOIN. Maar een JOIN is in veel gevallen heel veel trager dan een subquery. Als jij een webwinkel hebt dan heb je al een stuk of 6-8 tabellen die je regelematig tegelijk nodig hebt. Daar is je complexe (nouja, complex) query al en als je maar 1 veld uit een extra tabel nodig hebt dan is een subquery veel sneller dan een JOIN.

Maar denk ook aan triggers, stored procedures, functional indexes, partial indexes. Allemaal dingen die voor overhead zorgen, maar je database wel een hele klats sneller en vooral beter beheerbaar maken.

Daarom snap ik niet dat MySQL zulke grote plannen heeft terwijl ze dus de meest elementaire dingen (zoals controle op kolomtypes) nog niet onder de knie hebben.

MySQL kan echt heel groot blijven als ze hun zaakjes eens op orde zouden brengen. Zolang ze dat niet hebben zullen ze flink aan de marketing moeten om PostgreSQL en tegenwoordig ook SQLite voor te blijven.

[Verwijderd]

ODBC driver: http://www.mysql.com/products/connector/odbc/


MySQL heeft bovendien iets moois MySQL Lite, een pakket wat mega snel is met een simpele select of insert maar voor de rest vrij dom is, super voor query's die voor bijvoorbeeld site counters of pagina's met veel hit's waarvan de query's vrij simpel zijn.

PGSQL is alleen sneller (en beter) als de query's ingewikkeld zijn. Anders is MySQL heer en meester voor het relatief simpele werk.

MySQL heeft bovendien leuke ondersteuning vanuit Zend.
Zend bied erg mooie pakketten voor bedrijven om query's en programmatuur te versnellen.

[Verwijderd]

die odbc connector 3.52 is niet downloadbaar.. in ieder geval is het mij nog niet gelukt om die te downloaden.

en 3.51 ondersteund geen subqueries..(en zowieso geen mysql 4.1 ze hebben ook een stuklje authenticatie omgegooid dacht ik) Ik weet toevallig eens een keer waar ik het over heb ik gebruik die drivers namelijk voor een koppeling tussen mysql en delphi te maken.

[cvs79]

En wat te denken van de MSDE (Microsoft Desktop Engine), deze is ook gratis en wordt door microsoft duidelijk naar voren geschoven voor gebruik in webservers en kleine bedrijven

[RetepV]

MSDE heeft toch wel als grootste nadeel dat je maar 2 connecties tegelijkertijd open kunt hebben. Dat betekent eigenlijk dat je het alleen maar voor simpele dingen kunt gebruiken. MSDE is crippleware.

MySQL en PostgreSQL zijn wat dat betreft dus veel interessanter.

Overigens gaat mijn voorkeur naar PostgreSQL. Ik heb wel eens iets met Perl gemaakt dat op met een database moest werken en met PostgreSQL had ik dat veel sneller aan de praat. Ik weet niet meer waarom .

[Crazy D]

4 of 5 concurrent akties als ik het goed uit m'n hoofd zeg. Als ik het goed heb begrepen kun je wel met meerdere users connecten, alleen wanneer er 4 queries tegelijk draaien, zal de volgende user even geduld moeten hebben Nog steeds een beperking maar niet zo overdreven als jij stelt met 2 connecties... (en als het goed is heb je niet continue de connectie open dus die beperking valt dan in veel gevallen nog wel mee).
En het voordeel van MSDE is dat als het aantal gebruikers stijgt, je eenvoudig kunt overstappen naar het grote broertje (daar issie uiteindelijk ook voor bedoeld denk ik, klanten binden he ).

[mind_]

mooi nieuws voor de aanhangers/liefhebbers van open source software (waar ik onder val )
Voor een servertje thuis is het ook wel leuk, heb je zo een leuk forum of een andere applicatie draaiend op je eigen pc, en het kost niks

[Snipperrr]

En het aller belangrijkste het is legaal