SAP en MySQL bundelen krachten in nieuwe dbserver

De Duitse software-ontwikkelaar SAP en het Zweedse MySQL hebben een overeenkomst gesloten om gezamelijk een open source database server te gaan ontwikkelen. Op dit moment werken SAP en MySQL allebei nog aan eigen database servers, respectievelijk SAPDB en MySQL. In de toekomst moet er een gezamelijk product gepresenteerd gaan worden onder de merknaam MySQL. De primaire verantwoordelijkheden voor deze ontwikkeling komen te liggen bij MySQL. Beide bedrijven zullen zich gaan bezighouden met support op de database. Totdat de nieuwe database klaar is zal SAPDB door ontwikkeld worden onder de naam MySQL, voor de rest verandert er niks. Bij Internetnews.com is een artikel online gezet met informatie over een nieuwe database server die IBM wil gaan lanceren:

On the heels of several software announcements centered on data management, IBM is set to release in June DB2 Express, a smaller version of its flagship database targeted to the small- and medium-sized business market, internetnews.com has learned.

[...] "Basically, Express will be attractive to those that don't need all the features in DB2 Universal Database Version 8.1 -- such as high-volume transactions, full data warehousing capabilities and massive scalability," a source familiar with the product told internetnews.com.

Reacties (27)

In het bron artikel staat toch heel iets anders.

Nieuws Tweakers.net:
"De primaire verantwoordelijkheden voor deze ontwikkeling komen te liggen bij SAP. "

bron: heise
"Die primäre Verantwortung in der Entwicklung und im Produkt Management" dafür liegt bei MySQL, erklärt SAP-Sprecher Karl-Heinz Hess den SAP-Kunden in einem Rundbrief

Vertaling:
De primaire verantwoordelijkheden betreffende de ontwikkeling en product management liggen bij MySQL.

edit:
typo

OEPS, dat is nog een slordig vertalen, maar waar gewerkt wordt worden helaas fouten gemaakt.

Ik had het vier of vijf keer gelezen en dan zie je daar dus over heen. Maar ik pas het toch wel even aan, dit is inderdaad niet netjes.

Ruik ik een code merger van MySQL met sapDB? Het zou de functies uit 5.0 en 4.1 héél wat dichter brengen, en als de scheiding tussen db-server en tablespaces behouden blijft, is dit een uiterst grote stap voor MySQL. Ik kijk nu al uit naar nieuwe berichten omtrent de toekomst van deze samenwerking....

Alleen al het feit dat sapDB met MySQL samenwerkt zal wel opgenomen worden in de marketingpraatjes van MySQL...

Zo, dit is een behoorlijke ommezwaai van SAP. Nadat men eerder de ontwikkeling van de eigen database manager van een gesloten project heeft omgezet naar een "open source" project wil men nu dus op termijn helemaal stoppen met de ontwikkeling van een eigen database manager.

De keuze voor MySql is op zich niet zo verrassend. De samenwerking met Microsoft waarvan sprake was zou voor SAP een zachte knuffeldood tot gevolg hebben (MS wil zelf de markt voor CRM/HRM betreden en heeft daartoe al de nodige acquisities gedaan). In de nieuwe strategie van SAP overlappen de werkterreinen van beide bedrijven elkaar niet. SAP hoeft er in de komende tijd alleen nog voor te zorgen dat MySql de ontbrekende features in zijn engine stopt. Vervolgens kan SAP zich echt helemaal toeleggen op zijn eindproducten (CRM, HRM etc).

Als ik op dit moment bij SAP nog DB-engine ontwikkelaar zou ging ik eens serieus naar een nieuwe baan op zoek (binnen óf buiten SAP).

Goed nieuws, als dit zou inhouden dat MySql ook geschik wordt voor de grote databases waar nu MS SQL en Oracle de dienst uit maken dan is dat een prima ontwikkeling.

Waarom zou MySql op dit moment dan niet geschikt zijn voor grote databases?

Omdat MySQL (versie drie dan) eigenlijk niet eens een relationele database genoemd kan worden door het ontbreken van veel feature's.

Daardoor is MySQL een zeer snelle database en zeer geschikt voor database's die voor website's gebruikt worden, maar minder voor database's waarbij de informatie die erin staat garant staat voor veel geld. Zo heeft MySQL geen of amper mogelijkheden om terug te gaan in de tijd als er iets fout mocht gaan. Zo heeft MySQL (in ieder geval versie 3) geen roll-back mogelijkheden, toch redelijk lastig als er iets met de database is gebeurd wat eigenlijk niet de bedoeling was.

Kwa snelheid kan MySQL de grote redelijk bijhouden, kwa beveiligingen en ondersteunde instructies niet.

Omdat MySQL (versie drie dan) eigenlijk niet eens een relationele database genoemd kan worden door het ontbreken van veel feature's.

je maakt een aantal grove fouten
ten eerste is mysql geen database, maar een database management system.. en een relationele database is NIETS MEER dan een database waarin tabellen zitten (dus dat is mysql wel)

grote gebreken aan mysql zijn 't ontbreken van stored procedures, views, subselects, transactions, ..

maar 't merendeel hiervan wordt aan gewerkt of is bij bepaalde table types al geimplementeerd (zoals femme terecht al opmerkte)..

en 't InnoDB en 't BDB table type zijn ook gewoon gratis hoor

MySQL Max 3.23 wordt geleverd inclusief InnoDB en heeft dus ondersteuning voor transactions (incl. roll-back), row-level locking, versioning en foreign keys. Afhankelijk van de versie die je neemt heeft MySQL 3 dus wel roll-back mogelijkheden. Vanaf versie 4 zit InnoDB er standaard in.

De ontbrekende features zullen de komende jaren worden toegevoegd zodat MySQL voor steeds meer situaties toepasbaar zal zijn. Een paar jaar geleden, toen de InnoDB-engine nog niet was geïntegreerd, was MySQL een heel stuk beperkter dan nu. Hopelijk gaat de samenwerking met SAP zorgen voor snellere ontwikkeling van de nu nog ontbrekende high-end features. Voor SAP zal het aantrekkelijk zijn om hun ERP-pakketten op een goedkope open source database te kunnen draaien, aangezien dat hun klanten veel geld kan besparen. Bovendien kunnen ze Oracle er een hak mee zetten. De relatie met Oracle is toch al niet best meer sinds Oracle zelf in de ERP-markt is gegaan.

Ik denk dat hij doelde op het gebrek aan foreign keys in V3. Zonder foreign keys natuurlijk weinig RELATIES en dus weinig sprake van een RELATIONELE database.

Ik denk dat een belangrijk verschil tussen databases als oracle/db2 en mysql eerder is dat de schaalbaarheid te wensen over laat, oracle is ook helemaal ontworpen om te worden geclusterd en kan in die zin ook goed beheerd worden, zolang er het 1 database server is zal er niet veel verschil zijn tussen oracle en mysql, op wat features na dan...

subselects zijn helemaal geen noodzakelijke issue, in veel gevallen maken ze queries alleen onnodig traag....

edit: hmm, ik dacht toch echt te reageren op Bosmonster... anyway m'n reactie op Bosmonster:

Sorry, maar daarvoor staat 'relatie' niet in relationele databases. Relatie slaat op dat je een primary key hebt en dat daar andere velden aan gerelateerd zijn. Althans zo heb ik het geleerd.
Beter gezegd: een (één) tabel wordt ook wel een relatie genoemd.

MySQL kan niet alles wat de meeste databases kunnen. Zo ondersteund MySQL geen subqueries ik kan me voorstellen dat het ontbreken van dat soort functionaliteit erg lastig kan zijn bij grote databases. Correct me if i'm wrong

subqueries zitten in de 4.x release van mysql (1 van de laaste releases) als ik me ni vergis...

Subqueries zijn inderdaad erg handig, maar hebben niks te maken met de grootte van de database, maar met de gewenste toepassing.

MySQL is slecht in: parallel load ( komt vooral door matig locking gedrag, trekt de mysql database down bij veel concurrent connections)

Is geen probleem als er gebruik wordt gemaakt van InnoDB tables. We hebben hier eind 2001 ook schaalbaarheidsproblemen gehad door de table-locking van de MyISAM tables. Die problemen zijn opgelost door over te stappen op InnoDB tables.

Betekent dit dat je beter meteen de InnoDB tables van mySQL kunt gebruiken ipv. myISAM tables ?

Ik vermoed dat SED meer doelt op de onmogelijkheid van MySQL om met bijv. Sub-selects te werken . Via andere technieken kun je meestal dezelfde resultaten bereiken maar indien jouw toepassing in het verleden is gemaakt voor bijv. Oracle/MS Sql server dan wil je niet al je queries gaan herschrijven, met als gevolg dat MySQL bij een evaluatie als mogelijk vervangend database backend afvalt.

Deze overwegingen staat dus los van de performance die MySql zou kunnen leveren (welke zoals bekend meer dan uitstekend is).

kleine correctie op SED:

... grote databases waar nu MS SQL en Oracle de dienst uit maken...

de grote databases zijn toch IMS en db2/390, daar komen de databases die jij noemt toch echt niet aan te pas. (zonder er verder een waardeoordeel over te vellen!)

Blijkbaar een 390/zSeries tivosi, je hebt deels gelijk, het markt aandeel van MS SQL is niet groot vwbt 'grote' databases, maar IMS holt ook snel achteruit en Oracle, DB2, Progress en zelfs Sybase zijn toch echt behoorlijk vertegenwoordigd onder de 'grote jongens'. Vergeet niet dat Midrange UNIX systemen tegenwoordig de snelheidsrecords zetten op databases, ook de 'grote'. Die records worden gevestigd met DB2, Oracle, en, tot mijn grote spijt, met MS SQL. Kijk maar eens op http://www.tpc.org/tpcc/results/tpcc_perf_results.asp. Hier geen IMS vertegenwoordigd.

Betekend dit nou ook dat we vanaf nu voor SAPDB moeten gaan betalen?

SAPDB was GPL, en ook voor commercieel gebruik kostte deze niets.... MySQL kost daarentegen geld voor commerciele applicaties

Dat is niet helemaal waar. Alleen als jij zelf een applicatie distribueert, die MySQL gebruikt, en die zelf niet onder de GPL licentie valt, moet je een commercial license kopen. In alle andere gevallen vinden ze het heel fijn bij MySQL als je een license koopt, maar is het niet verplicht.

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 or other OSI approved license or not.

Totdat de nieuwe database klaar is zal SAPDB door ontwikkeld worden onder de naam MySQL, voor de rest verandert er niks.

En wat gebeurt er dan tot die tijd met MySQL?

Die ontwikkelt zich nog onafhankelijk gewoon verder.
Het is wat ongelukkig gekozen omdat het nogal verwarrend is twee verschillende software producten te hebben die bijna gelijk zijn en nog de zelfde naam hebben ook, maar alleen de naam verandert even van sapdb naar mysql.
Waarschijnlijk om twee redenen:
1) het moet in de toekomst toch zo verder heten en dan went het alvast wat makkelijker voor de klanten
2) binnen sap werkt men ook met andere producten die beginnen met my (mySAP) zodat het wat logischer binnen het profiel past.

Wat heeft die laatste zin over IBM en DB2 met de rest van het artikel (en met name de topictitel) te maken Of was dit bedoeld als een soort verzamelbericht voor allerlei dingen over databases?