Databasegiganten in de arena: IBM vs. Oracle

Het belang van databases neemt steeds meer toe. Ook in het aantal gebruikte databaseproducten zit nog een flinke groei. In dit artikel bij TechNewsWorld worden onder andere de zware jongens van Oracle en IBM eens goed tegen het licht gehouden. Oracle 9i wordt gezien als de meest robuuste onder de relationele databases en ook in beschikbaarheid scoort deze software goed. Maar Oracle 9i is ook het duurste product op de markt. De vraag is dus of je die topkwaliteit wel nodig hebt. DB2 van IBM is een goede tweede in deze vergelijking, qua techniek ligt Big Blue licht achter ten opzichte van concurrent Oracle. De prijs van dit product is ook wat lager dan het bedrag wat voor 9i neergelegd zou moeten worden.

Als derde speler in de database-markt vinden we SQL Server van Microsoft. Dit product is bezig aan een flinke opmars. In het afgelopen jaar kwamen achttien procent van de verkochte licenties in de handen van Microsoft terecht, een groei van zeventien procent ten opzichte van 2001. SQL Server neemt met deze omzetcijfers wereldwijd de derde plaats in. Deze plek behoorde zeven jaar geleden nog toe aan Sybase, een product dat nu nog goed is voor drie procent van de markt. De mogelijkheden binnen SQL Server zijn dan niet zo uitgebreid als die van Oracle 9i en DB2 maar op het gebied van beheerbaarheid blinkt dit product uit. Drie jaar geleden werd SQL Server niet in een adem met DB2 en 9i genoemd:

"Microsoft leads all vendors in terms of manageability," Graham said. "That's [an] aspect of why they're doing so well."

She noted that SQL Server is a relatively simple database, with fewer bells and whistles than either Oracle's or IBM's offering. At the same time, SQL Server is now considered an enterprise-class database in certain situations. Three years ago, it would not have been placed in the same class as either IBM or Oracle.

Reacties (48)

[Verwijderd]

Deze hele vergelijking is op nogal op hoofdlijnen gebaseerd, ik had graag meer details in het artikel terug gevonden. Zo staat bijvoorbeeld nergens wat precies de functionele verschillen zijn tussen DB2 en ORACLE 9i.

Even verder in het artkikel staat dat 70% van de functionaliteit van deze beide databases zelden door applicaties gebruikt worden. Over welke functionaliteit hebben ze het dan precies?

Dat SQL Server aan een grote opmars bezig is lijkt mij duidelijk. Het is flexibel, snel inzetbaar (installatie, enz), goed gedocumenteerd en presteerd ook nog eens goed.

Voor ontwikkelaars (niet DBA'ers) is het dan ook een soort van database hemel. Heel toegankelijk allemaal, eenvoudig te begrijpen en met goed toepasbare functionaliteit. Een echte hit dus, en een hele generatie groeit nu op met SQL Server kennis.

Dus als Microsoft geen gekke dingen doet, en het product echt blijven verbeteren dan zullen ze over een paar jaar nummer 2 en mischien wel nummer 1 in deze parkt zijn.

Wat belangrijk is om verder te groeien is dat ze technishe beperkingen m.b.t. applicatie ontwikkeling blijven wegnemen. Een groot deel van de kosten die bij een applicatie komen kijken zit in het om beperkingen heen werken tijdens de ontwikkeling.

Enkele voorbeelden hiervan:

* Een index is beperkt tot max 300 byte keys. Dus een kolom met varchars groter dan dit indexen is niet mogelijk.

* Een varchar kan nooit groter zijn dan 8KB. Je kunt het text datatype gebruiken, maar dan treden er weer andere beperkingen op.

* Text objecten kunnen (vanwege andere manier van opslaan) niet hetzelfde behandeld worden als varchars. Hierdoor wordt de database gereduceerd tot domme opslag laag zonder enige flexibiliteit. Niet meer van deze tijd, waarin een hoop logica in de vorm van stored procedures zo dicht mogelijk bij de data geplaatst wordt.

* Een record mag niet breder zijn dan 8KB (page groote). Als je echt veel velden heb en het zijn geen 1 op N vergelijkingen, dan is het echt een ramp om een record in stukken te hakken en in verschillende tabellen op te slaan. Je kunt dan geen dataset operaties meer uitvoeren op de tabel. De tabel is immers opgedeeld over meerdere tabellen. Een voorgestelde standaard 'oplossing' van een view over deze meerdere tabellen heen werkt alleen voor selects zonder bijwerkingen. Bij een insert krijg je problemen met NULL velden, aangezien die toch opgegeven moeten worden in het insert statement. Kortom, je loopt tegen nog meer beperkingen aan.

Dit is slechts een topje van de ijsberg, en ik weet dan andere databases het in sommige opzichen minder goed doen.

De meeste beperkingen zijn databse architectuur gebonden (met name de fysieke manier van opslaan). Deze beperkingen maken het voor de database leverancier gemakkelijker om een sneller product neer te zetten.

Het probleem hiermee is dat de resulterende snelheid winst meestal niet benodigd, nog benut zal worden. De hoge prijs die tijdens het ontwikkelen betaald moet worden om omslachtig om deze probemen heen te werken is veel belangrijker. Dit om de problemen heen werken beinvloed ook sterk de kwaliteit van de resulterende eindproduct en is dus ook voor de database leverancier van groot belang.

Wat ik dus graag zou willen zien is dat dit soort restricties relaxed zouden worden, en dat mag in de situaties waar dat van toepassing is best wat performance kosten.

Het is nogal een verschil als je een standaard SQL constructie kan gebruiken die netjes integreerd met de rest van het systeem i.pv. zelf een complexe en niet in het systeem geintegreerde oplossing bedenken en maken.

De eerste optie kost geen extra tijd, de laatse kan weken tot zelfs maanden duren en alle code in een applicatie beinvloeden. Dit is een BIG issue dus.

[a.prinsen]

je blind staren op het weg halen van technische beperkingen heeft ook zo zijn nadelen.
Ik denk dat je ook moet kijken naar de huidige beschrikbare work-arounds. Af en toe zijn zelfs workarounds gebruiks vriendelijker dan de aanpassing die nodig zijn om het te "kunnen".

Tevens kan prestaties met elkaar vergeleken worden tussen een work around en een technische aanpassing. Het is namelijk niet zo dat een technische aanpassing meteen zorgt voor betere prestaties.

Workarounds vs nieuwe Techniek
Gebruiks gemak afwegen
Benchmarken (prestaties) afwegen
Behoefte analyse van klanten (spul erin stoppen dat niemand wilt = slecht voor je programma)
kostenplaatje (implementatie,test etc) vs beoogde meerwaarde.
-----------------------------------------------+
ja of nee

[Verwijderd]

Ik ben met je eens dat er niet op techniek blind gestaard moet worden.

Wat betreft prestaties is het zo dat een door de database 'relaxte' handeling best meer tijd mag kosten. Alle overige 'standaard' operaties gaan zoals vanouds lekker snel dan.

De complexe handelingen die ervoor nodig zijn op de datalaag worden dan door de database leverancier (low-level) uitgevoerd en niet door de ontwikkelaar (high-level) van de eind applicatie. Er kunnen dan ook geen bijwerkingen die weer nieuwe problemen veroorzaken ontstaan.

Het op low-level uitvoeren is stabieler, sneller en laagdrempeliger onder alle omstandigheden. Je kunt er dus alleen mee winnen.

De meeste work-arounds voor de genoemde problemen zijn of afhankelijk van buiten de database bevindende processen of roepen weer nieuwe SQL beperkingen op. Het kan ook omvangrijke datamodel aanpassingen tot gevolg hebben die doorwerken in de applicayie software. Kortom een hoop werk voor iets wat elders opgelost hoord te zijn.

Wat betreft de behoeften van klanten, daar kun je je als databse leverancier flink op verkijken.

Stel dat ontwikkelaars gewend raken aan het om bepaalde beperkingen heen werken. Dan zie je als leverancier bij eindklanten dus een hoop bepaald type constructies (met als doel een ander probleem te omzijlen). Dit betekend echter niet dat er een grote begoefte is aan het vernellen of gemakkelijker maken van dit soort constructies. Er is dan behoefte aan het echt oplossen van het probleem waar all die constructies voor verzonnen zijn.

Je kunt dus stellen dan een database leverancier twee klanten heeft.

1. De eind klant, waaraan het database pakket wordt verkocht. Van deze klant is belangrijk om te leren wat de operationele wensen zijn en wat voor soort applicaties er op verwerk worden en met welk doel.

2. De ontwikkelaars van applicaties voor dit soort systemen. Deze mensen weken echt met de database en bepalen uitendelijk in grote mate hoe successvol de database kwa prijs en prestatie en stabiliteit ingezet wordt. Niet zelden wordt een database gewoon door de software leverancier meegeleverd (in inder geval bij SQL Server).

Probeem is dat veel mensen de rol van de ontwikkelaar niet zien of onderschatten. De ontwikkelaar wordt niet als klant gezien, terwijl dit zeker voor de technische aspecten van het database product wel degelijk wel het geval is.

Het kort door de bocht stelen dat de eindklant bepaald of bepaalde technische beperkingen relevant zijn of niet is dus belachelijk. Dat zou overeen komen met het stellen dat de leverancier bepaald (of een derde) wat de klant moet kopen.

Dit laatste is een leuk fenomeen, omdat dit jarenlang het geval is geweest in database land. Oracle verkocht zijn database bijvoorbeeld aan het management (van een onderneming en vervolgens gind die ondernemening shoppen voor applicatie leveranciers voor die database.

Die tijden zijn gelukkig voor het gootste geval voorbij en als oracle en andere bedrijven niet sbel realiseren dat zij niet langer 'de macht' hebben, dan gaan ze flink onderuit.

Ik zit nu al te wachten op de flame wars tegen microsoft over 3 jaar, als ze de grootste in database land zijn geworden. Hoe kan dat nou he....zal wel niet eerlijk gebeurd zijn!

[MisterBlue]

Het kort door de bocht stelen dat de eindklant bepaald of bepaalde technische beperkingen relevant zijn of niet is dus belachelijk. Dat zou overeen komen met het stellen dat de leverancier bepaald (of een derde) wat de klant moet kopen.

Uiteindelijk zal de eindklant de keuze maken, hopelijk ondersteund door een aanbeveling van zijn technici.
Wat de eindklant wil weten is of de techniek zijn zakelijk probleem oplost. Daarbij wordt ook wel meegenomen de onderhoudbaarheid, betrouwbaarheid, etc.
Wat ik probeer aan te geven is dat de tijd dat technici besluiten nemen over aankopen voorbij is. We beinvloeden nog steeds wel de besluiten, maar als het geld uitgegeven moet worden is het toch de eindklant die dat besluit neemt.

Ik heb zelf nog het gevoel, dat we als technici te veel bezig zijn met africhten van de machines, i.p.v. oplossingen voor de klant/eindgebruiker bedenken.

[Little Penguin]

Ik zit nu al te wachten op de flame wars tegen microsoft over 3 jaar, als ze de grootste in database land zijn geworden. Hoe kan dat nou he....zal wel niet eerlijk gebeurd zijn!

Als men SQL-Server aan het os gaat koppelen is die opmerking dat het oneerlijk gebeurt is volkomen terecht.

Als men het echter helemaal op eigen kracht gedaan heeft is het een ander verhaal. Overigens de weinige keren dat ik met SQL server gewerkt heb kwam ik nogal wat beperkingen tegen tov Oracle. Dus bedrijven die veel leunen op een database zijn mijns inziens nog steeds beter af met Oracle, ook al is de prijs best hoog.

Als iemand zegt dat het niet (helemaal) eerlijk gegaan is in de browser wars waar men Netscape de markt uitgedrukt heeft door o.a. IE in het OS te klemmen heeft hij of zij gelijk. Anderzijds is het wel zo dat Netscape (is nu Mozilla - gewoon eens proberen...) lange tijd sterk achtergelopen heeft tov IE. Maar dat is met Mozilla en NS7.1 inmiddels omgedraaid in het nadeel van IE.

[EfBe]

In yukon (sqlserver 2004) zijn veel van deze zaken opgelost die je aanstipt. Het is inderdaad een raar gegeven dat je als database-consumer (code layer die de database aanroept) rekening moet houden met bv blobs, textfields en limieten die de database eigenlijk voor je verborgen zou moeten houden. Op dit moment zijn alle grote databases 'gezegend' met een API die bol staat van de poliepen van functionaliteit: lees maar eens een blob uit in Oracle, je moet veelal een file pointer oid verwerken, ipv dat de blob gewoon in je recordset zit als field. (aan de ene kant logisch als je erg grote blobs hebt, aan de andere kant, dit komt zelden voor, dus wil je een feature waarbij je dat op kunt geven).

Transparantie is dus nodig. Yukon brengt je dat, maar ik denk tegen die tijd Oracle ook.

[Database freak]

SQL Server loopt hoofdzakelijk nog achter op beveiliging. Ze hadden een grote achterstand op Oracle/DB2 met de 7.0 versie hebben ze een grote stap gezet als enterprise DB, de 2000 versie was hier slechts een (kleine) verbetering op; bevat dezelfde kernel echter met wat tweaks die de schaalbaarheid vergroten. Zelfs deze verbeterde 7.0 versie is nu al 3 jaar oud, terwijl 9i en DB2 recente versies veel nieuwer/recenter zijn, en daardoor verder ontwikkeld.
Volgend jaar komt er een geheel nieuwe versie uit, Yukon, die een grotendeels rewrite van de kernel zal bevatten. Ook beveiliging zal veel beter geintegreerd zijn in het product, naast uitbreiding op DWH-gebied, clustering en integratie van programeerbaarheid van de DB. Ik verwacht dat dit product qua mogelijkheden sterk in de buurt zal komen van 9i of de uitkomende 10i en Oracle het nog een stuk moeilijker zal gaan krijgen.

Enige voordeel voor Oracle is hun installed base; bedrijven die veel met databases doen doen dat al vaak al lang en zijn lang geleden met Oracle begonnen en hebben hun programmatuur/beheer/kennis/mensen afgestemd op dit product en schakelen zo niet makelijk over.

[Verwijderd]

Wat denk je van platform onafhankelijkheid? Oracle draait niet alleen op Microsoft op op AIX, maar op zo ongeveer elk platform. Dat is toch zeker een groot voordeel.

Verder is Oracle als RDBMS wel een aantal stappen verder dan MS*SQL. Ondanks alle integriteitcontroles etc. performed Oracle toch nog bijna net zo goed als mysql zonder al deze controles en beter dan welke database dan ook met in de buurt komende controles en methodes. Daar kan je van alles over roepen (als bezwaar), maar knap blijft het.

De technologische voorsprong wordt steeds kleiner (is daar niet een of andere wet over voorsprong en remmen?) maar de voorsprong is er nog zeker. Voor applicaties die 24/7/365 in de lucht moeten zijn met een huge database (denk aan TB's), is Oracle nog steeds veruit de beste keuze. Grappen als parallel server zijn nog steeds uniek qua kwaliteit

Uiteraard moet wel je ten aller tijde het juiste middel voor het juiste doel kiezen. Dat betekend dus dat Oracle niet altijd de beste keuze is voor een applicatie. (denk b.v. aan een forum, onzin om dat in Oracle te zetten) Zeker het kostenplaatje van Oracle is een nadeel.

[bruij025]

Ik heb me altijd afgevraagd waarom de meeste Oracle Database Administrators niet eens de moeite nemen om een online backup te doen. Verder vind ik Oracle ronduit te duur voor het midden en kleinbedrijf. Verder zie ik vooral DB2 bij banken en verzekeringsinstellingen en is de spoeling Database Administrators met een gedegen kennis erg dun, dus duur. SQL Server daarintegen is sinds versie 2000 een serieuze partij geworden. Vroeger zag ik veel nadelen bij het gebruik van SQL Server, zeker als het over performance ging bij grote databases en het fenomeen tablelocking. Op dit moment zie ik die nadelen snel verdwijnen. Er is alleen nog een groot struikelblok voor SQL Server en dat is grote 'klooi' gehalte van de interface. Ik ken een hoop systeembeheerders die denken dat ze verstand hebben van SQL Server en het er wel even 'bij' doen. Volgens mij ben je dan verkeerd bezig.

[napel25]

SQL Server kan inderdaad steeds grotere databases aan. Maar dat moet ook wel, omdat de gratis databases als mysql en postgresql ook steeds door groeien.
Daarbij hebben de gratis databases het voordeel een mogelijke opstap database te zijn naar Oracle voor de wat meer handige IT-ers die houden van LEGO systemen t.o.v. kant en klare produkten als MS SQLServer.

Het kant en klare produkt van SQL Server is in het begin erg toegankelijk. Maar wanneer je dicht op de grenzen van SQL Server komt, loop je regelmatig tegen problemen aan waarvan de oplossing niet voor de hand ligt. Dan heb je een goed opgeleide DBA nodig om dat op te lossen. Op dat moment is SQL Server t.o.v. Oracle een voordeel kwijt.

[whoami]

Een database zoals oracle of sql server is nog altijd niet te vergelijken met een toy als MySQL.
Daarnaast zou ik SQL Server nu ook niet echt een 'kant-en-klaar' product durven noemen. Wil je een echte performante SQL Server DB die meerdere concurrent connecties aankan, dan komt er ook nog heel wat tuning (en kennis over de architectuur) bij kijken.
Een serieus bedrijf met serieuze bedrijfs-kritische enterprise app's heeft zowiezo een goeie DBA nodig, die zijn vak kent. Of je nu Sql Server of Oracle gebruikt, maakt niet uit.

[mphilipp]

Ik ken een hoop systeembeheerders die denken dat ze verstand hebben van SQL Server en het er wel even 'bij' doen. Volgens mij ben je dan verkeerd bezig.
Dat is nou precies mijn punt (en dat zie je eigenlijk overal gebeuren in de IT): al die wizards en autopilots maken van iedere sukkel en 'expert'. Alleen weten ze niet wat ze doen en denken ze zo dat ze heel wat kunnen omdat ze het juiste knopje in kunnen drukken. Ondertussen hebben ze geen flauw benul wat ze precies aan het doen zijn.
Helaas gaat Oracle ook die kant op. Waarom? 'De klant wil dat'. Fout: de klant wil een beheersbaar product, maar een wizard maakt niet noodzakelijkerwijs een beheersbaar product. Misschien moet men er meer effort in steken om mensen duidelijk te maken dat wat het RDBMS doet eigenlijk razend ingewikkeld is, en met een wizard wordt dat niet ineens heel makkelijk. Het kan zo lijken, maar als je niet weet wat je doet kan het zelfs tegen je gaan werken.
Wie denkt dat dit onzin is, ik heb hier nog een lekkere dikke Concepts Manual (2 dikke boeken) van Oracle 8i liggen. Ter leerlingh ende vermeack...

[Standeman]

De klant wil gewoon voor 3 knaken op de eerste rij zitten en dat is ook niet verwonderlijk. Vaak is de concurentie moordend en als op (welk gebied dan ook) een stuivers kan uitsparen, dan behaal je weer voordeel op je concurentie omdat je je dienst/product weer goedkoper kan aanbieden.

De wizards etc. zijn gewoon erg handig wanneer je de productiviteit van de dba-er / ontwikkelaar wilt verhogen. Dat is naar mijn opzicht ook vaak hard nodig!

[Verwijderd]

Het is toch goed dat er zoveel concurrentie tussen deze versies zijn dat zorgt er tenminste voor dat ze een beetje hun best doen.

En het is maar net wat je er mee wilt doen. Want dit is dus niet te vergelijken met een eeste de best MySQL versie want je koopt zo'n pakket om je bedrijfs databases op te draaien en als die plat gaan heb je een probleem. Dus moet het goed spul zijn. (op dat vlak zijn deze spelers dan ook beter dan MySQL)

En wat bijv Oracle ook fout doet is hun dure alleskunnende 'mercedes' proberen te verkopen terwijl ze met hun 'light' versie ook een leuk marktaandeel mee kunnen pikken. Desnoods voor een prikkie als 'reclame' voor hun duurdere versie.

MS pakt het gewoon handig aan door hun albekende marketingstrategieen toe te passen en het blijkt maar weer dat ze daar succes mee hebben. Wel jammer dat zo op het technlogische vlak achterblijven want dat weerhoudt velen om voor hun produkten te kiezen.

IBM zit er zo'n beetje tussenin. Ze hebben een goed produkt want goedkoper is dan Oracle maar ook nog zat kan en hun reclamebudget is ook redelijk groot.

[whoami]

Hoezo SQL Server loopt achter op het technologische vlak?

Ik geloof dat vrijwel alles dat beschikbaar is op Oracle, ook met SQL Server mogelijk is.

[EfBe]

Ik heb lang dit ook gedacht, maar het is niet zo. De verschillen zijn niet zo schokkend dat je denkt "zo, sqlserver is de ms access van de grote jongens database wereld", maar de verschillen zijn er wel degelijk.

Een van de meest in het oog springende is MVCC. (multi version concurrency control). SqlServer ontbeert dit. Je loopt hier tegenaan als je in een transactie zowel wilt lezen als schrijven naar/van dezelfde tabellen via 1 connectie. De write-lock (exclusive lock) houdt de lees-actie tegen. Je kunt hier omheen werken middels een 'read uncommitted' lock hint, maar dit houdt in dat je ook uncommitted reads van andere transactions leest, en dat wil je wellicht niet. MVCC lost dit op.

Er zijn nog wel meer dingen, zoals het 'live' backuppen van een database. Oracle kan dit, ook weer om het MVCC, altijd, SqlServer niet, omdat rows gelockt blijven ivm transactions.

(dit is mn 4e message in deze thread, ik hoop dat deze WEL zichtbaar blijft, mods. Mijn dank).

[whoami]

Sql Server kent toch roles?
Server roles, DB roles, Application roles.

[napel25]

Wel roles, geen profielen.

[whoami]

Wat is het verschil dan?

[napel25]

SQL Server kent geen profielen. Dat had ik toch wel fijn gevonden op de SQL Servers die ik beheer.
Verder heb ik nog niet gezien dat SQL Server met paralel server kan op alle nodes tegelijk kan updaten e.d.

[moser]

jammer dat in de vergelijking MySQL niet is opgenomen
Dan kon bekeken worden hoe de dure pakketen presteren ten opzichte van een gratis pakket.

[EfBe]

Het gaat over databases, niet over toys als MySql die geen:
- foreign keys
- triggers
- stored procedures
- check constaints
- user functions
- replication
etc.
ondersteunt.

[*CableGuy*]

Ok, MySQL is verre van een volledige database, dat ben ik met je eens. Maar je moet de feiten wel juist noemen, zo ondersteunt MySQL standaard replication en als je gebruik maakt van de InnoDB table handler beschik je ook over foreign keys.

Oh, transacties had je nog kunnen noemen, maar die zitten ook in de InnoDB functies ;-).

[jochemd]

en als je gebruik maakt van de InnoDB table handler beschik je ook over foreign keys.

Helaas is dat niet waar. MySQL ondersteunt geen foreign keys.

De SQL standaard (ISO/IEC 9075-2, verkrijgbaar in de betere bibliotheek of te koop bij het NEN) definieert voor foreign keys onder andere het volgende:

©ISO/IEC ISO/IEC 9075-2:1999 (E)
11.8 <referential constraint definition>
(..)
3) Case:
a) If the <referenced table and columns> specifies a <reference column list>, then the set of <column name>s contained in that <reference column list> shall be equal to the set of <column name>s contained in the <unique column list> of a unique constraint of the referenced table. Let referenced columns be the column or columns identified by that <reference column list> and let referenced column be one such column. Each referenced column shall identify a column of the referenced table and the same column shall not be identified more than once.

Hetgeen MySQL heeft geimplementeerd en foreign keys noemt gedraagt zich echter heel anders. Uit de MySQL handleiding:

A deviation from SQL standards: if in the parent table there are several rows which have the same referenced key value, then InnoDB acts in foreign key checks like the other parent rows with the same key value would not exist. For example, if you have defined a RESTRICT type constraint, and there is a child row with several parent rows, InnoDB does not allow the deletion of any of those parent rows.

Als je even nadenkt over wat dit betekent als je cascading updates hebt en je een key een paar keer wijzigt dan wordt hopelijk duidelijk hoe ontzettend gevaarlijk het is om voor je data integriteit te vertrouwen op MySQL foreign keys.

[Q]

Okee, MySQL mist zeker een hoop en is misschien een toy te noemen, maar hoe staat het met een open source database als Postgresql in verhouding tot bovengenoemde databases?

[Verwijderd]

http://www.tweakers.net/nieuws/20768

[EfBe]

kom OP nou, die test is gedaan met een crappy JDBC driver voor sqlserver (early beta). Joh, geen wonder dat sqlserver slecht presteert.

[Verwijderd]

dat staat er eerlijk bij.. ik heb die test ook niet gedaan. bovendien, dan had microsoft zelf maar een goede jdbc driver moeten schrijven hoor.

[Verwijderd]

The MySQL database server is available for free under the GNU General Public License (GPL). Commercial licenses are available for users who prefer not to be restricted by the terms of the GPL.

[whoami]

MySQL is éénmaal een database die totaal niet te vergelijken is met producten zoals SQL Server, Oracle of DB2.
MySQL mist gewoon nog een aantal essentiele functionaliteiten (subqueries, referentiele integriteit, views, stored procedures, ...)
Zolang MySQL deze mogelijkheden niet bevat, kan MySQL ook geen RDBMS genoemd worden, en kan het zeker geen concurrent van deze 3 eerder genoemde producten zijn.

[King007]

Kleine correctie: vanaf MySQL 4.1 worden subqueries ondersteund.

[whoami]

In SQL Sever heb je, naast de GUI interface als DBA nog een hele set T-SQL statements en stored procedures tot uw beschikking.
De MS filosofie voor Sql server is niet diegene die jij beschrijft. Er zijn vele boeken beschikbaar die handelen over tuning van Sql Server, hoe je het best je DB opzet en configureert, hoe je filegroups kan gebruiken, tips en best practices over hoe groot je fill-factor van je tables mag zijn, ...

Ik denk dat de mening van veel mensen wb Sql Server redelijk achterhaald is, of beinvloed wordt door het (soms onterechte) slechte beeld dat bepaalde mensen over MS hebben.

[mphilipp]

Ik denk dat de mening van veel mensen wb Sql Server redelijk achterhaald is, of beinvloed wordt door het (soms onterechte) slechte beeld dat bepaalde mensen over MS hebben.
Lezen is ook een vak...
Ik stel dat wizards en automagische tuningtoestanden geen DBA'er maken van een ondeskundig persoon. Men staart zich blind op een zogenaamd makkelijker te beheren product als er allerlei wizards en automaten in zitten. Maar dit zijn allemaal generieke oplossingen. Achterhaald is mijn mening zeer zeker niet, want ik zie het gewoon nog dagelijks in de praktijk gebeuren. Ook bij Oracle. Zogenaamde Designer specialisten die niet eens weten hoe je een view aanmaakt. Zo kan mijn moeder ook DBA worden als je alles op cruise control zet en met een wizard je beheer doet. Totdat er iets aan de hand is waar je kennis voor nodig hebt.
Mijn kritiek is dus geen kritiek op MS persé, maar meer op de overgewaardeerde wizards enzo. Die dingen zorgen er gewoon voor dat de echte kennis verloren gaat.

[aphx]

Oracle 9i wordt gezien als de meest robuuste onder de relationele databases

Ik ben beetje voorstander van DB2 op een As/400 (iSeries). Ik kan me niet voorstellen dat dat minder robuust is dan Oracle 9i op welk platform dan ook.

[LostboyArno]

Database giganten met IBM en zonder Progress. Beetje ongeloofwaardig.

[Battle Bunny]

Juist! Op welke plaatst staat Progress? Het hele financiele systeem bij ons draait hier op, en het draait als een tiet! Super stabiel, snel en nog een programmeer taal ook... Volgens de mensen die voor onderhoud langskwamen was dit toch echt wel één van de beste DB pakketjes, en nog vaak gebruikt ook!

[Marcelloz]

Progress is geen grote jongen qua omzet. En hun database is alleen met hun eigen spullen te benaderen, dus totaal niet open. (in ieder geval 1,5 jaar geleden niet). Dus de kosten zijn duur uiteindelijk als je wilt integreren of interfacen.

[Verwijderd]

Een veel interessantere ontwikkeling is dat SAP nu haar eigen gratis database aan MySQL geeft en hen steunt in de verdere ontwikkeling.
SAP zal er voor willen zorgen dat haar producten prima op de in nabije toekomst ontwikkelde MySQL kan draaien. Hetgeen voor de grote reuzen wel degelijk problemen kan gaan zorgen.

Zie ook reeds eerder verschenen bericht:
http://www.tweakers.net/nieuws/27131/

[Verwijderd]

Dit loopt met een sisser af.

[Verwijderd]

als ze nu ook even mssql voor unix uitbrengen is de kans nog groter dat ze hun marktaandeel verhogen.
mssql is wat dat betreft een vreemde eend in de bijt.

[EfBe]

Waarom voor unix? Win2k3 is net zo solide. Ik denk dat men eens op moet houden met het napraten van elkaar omtrent de robuustheid van operating systems. Kom eens met een wetenschappelijk onderzoek hiernaar, zodat er bewijs is omtrent wat solide is en wat niet.

Eigen ervaringen tellen niet, want een ander heeft wellicht precies het omgekeerde aan ervaringen. Als men wetenschappelijk aan kan tonen dat windows 2003 minder goed scoort (en dan niet op basis van statistische tests, maar op onderzoek naar design en implementatie ervan) en unix (closed source, zoals AIX of HP-UX of open zoals Solaris) beter, dan pas kun je zeggen: ja, het is voor sqlserver beter dat het ook op unix uitkomt.

Echter, ik geef het je op een briefje, over een paar jaar (2 a 3), zijn de enige unix databases die nog over zijn de databases die op linux draaien, kosten ze evenveel zoniet minder dan SqlServer en kijken ze tegen de nek aan van SqlServer (2000 en Yukon) op win2k3.

[nhimf]

Mensen hebben eenmaal een voorkeur. Waarom zou je windows aanschaffen om mssql te kunnen draaien en je daardoor ook allerlei andere software moet aanschaffen, omdat het niet onder windows werkt.
Wat hij wil zeggen is eigenlijk waarom brengt MS niet hun SQL server onder *nix uit? Ik ben het met hem eens dat ze dan toch een best groot publiek kunnen aanspreken die het dan zouden overwegen.
Hij heeft ook helemaal niets gezegd over dat linux beter is dan windows ofzo. Hij vraagt zich (terecht) af waarom er geen mssql voor *nix is.

Dus jouw opmerking over napraten over robuustheid over os-en is in dit geval dikke onzin, daar heeft hij het niet over gehad. Dus een +3 inzichtvol voor jouw opmerking is imho onzin.

[Verwijderd]

<rant>Er zijn mensen die het een waste vinden om een window manager te laten draaien op een server bijvoorbeeld...
<rant>

WINNT servers hebben hun nut een zeker ter ere hiervan is de groei van toepassingen ervan. Echter blijven *nix'en vaak een technisch interessantere oplossing. Vaak qua performance, beschikbaarheid van tools en software en uitwisseling van expertise uit verschillende disciplines. Ik heb Linux bakkies met RedHat, een maatje die BSD freak is kan makkelijk even overnemen als het moet een een collega die hardcore solaris user is is ook niet verloren als ik hem shell toegang biedt. Verder hebben we allemaal vergelijkbare databases draaien, iedereen heeft zijn basic MySql, maar voor de serious stuff Postgres varianten, weeralom, ik gebruik de RedHat variant, zij dan de "pure" Postgres, niemand die erom moet huilen. Op werk uiteraard SQL2000 en dat is een leuk product met zelfs meer features dan mijn "gratis" servers maar als ik geld moet neerleggen voor top qualiteit dat ga ik echt wel naar DB2, niet zozeer iets tegen Oracle gewoon voorkeur voor IBM

[DavidAxe]

Waarom zouden mensen die voor een Linux oplossing kiezen anti-MS moeten zijn?

De keuze van de database hangt er natuurlijk vooral van af waarvoor de database gebruikt gaat worden. Meestal wordt een database indirect gebruikt (dus d.m.v. een applicatie die de gegevens in de database aanspreekt) en kies je dus een database waar de applicatie goed mee overweg kan. Als je daarbij niet gebonden wilt zijn aan welke (beperkt aantal) interfaces de database fabrikant levert, dan val MS SQL al snel af (wat overigens ook voor veel andere databases geldt).