Database keuze

[Verwijderd]

Beste mensen,

Ik zit met een probleem waarop ik tot op heden geen bevredigend antwoord heb ontvangen.
Binnen onze organisatie ontwikkelen we software allemaal gebaseerd op .net, heel af en toe een php opdracht. In de toekomst zullen er ook Androide applicatie worden ontwikkeld.

Ik wil graag eens een objectief antwoord krijgen op de vraag wat op dit moment de beste DBMS is. Performance, betrouwbaarheid, onderhoudbaarheid en repliceren hebben de hoogste prioriteit. Tevens moeten de DBMS kunnen worden geïnstalleerd op een Windows omgeving (XP, Vista, 2003, 2008 en Win7).

We ontwikkelen webapplicaties (ASP.net en Silverlight) , Server cliënt applicaties en WFC services.
Als ORM gebruiken we XPO (eXpressPersistent Objects) van DevExpress.

Binnen onze organisatie hebben we een groep developers die zweren bij MSSQL, Postgre, MySql en Firebird. Ik zou graag wat eenheid willen creëren om één DBMS te kiezen.

[jbdeiman]

@Gloat:

Wat zijn de precieze vereisten van het DBMS? Betaald/ onbetaald, open source of niet (zit ook verschil in) Wat moet het kunnen, en wat mag absoluut niet?

Heel kort door de bocht gezegd:
- MSSQL: Microsoft houdt er hier in een aantal gevallen een beetje een eigen standaard op na.
- PostgreSQL: Is een stuk stricter dan MySQL en schijnt prima te functioneren in webomgevingen. Zelf geen ervaring mee.
- MySQL is vrij losjes, als je een string van 30 karakters in een veld van 20 lang probeert te proppen, gooit die zelf de laatste 10 karakters wel weg (by default, dit is aan te zetten!).
- Firebird ken ik helemaal niet.

Maar de vraag is dus:
- Wat zijn de vereisten aan het dbms
- Moet het DBMS alleen onder windows werken, of ook op linux (niet via Wine oid, dat wil je niet!)
- Mag het geld kosten, en zo ja wat zijn de kosten
- Hoe groot/ ingewikkeld worden de databases (de 1 gaat daar beter mee om dan de ander)
- Moet het foreign keys e.d. (stukje database integriteit afvangen) ondersteunen
- Moet er veel (en vooral uitgebreide) informatie voorhanden zijn (ga je meestal al richting opensource)

Ga zo maar door met het lijstje. Voor verschillende situaties zou je ook een ander dbms aangeraden krijgen.

[Sebazzz]

Het belangrijk is dat je een .NET compatible dataprovider voor je RDBMS kan vinden. Voor Postgres is die er, voor MySQL ook.

- MSSQL: Microsoft houdt er hier in een aantal gevallen een beetje een eigen standaard op na.

Dat geven ze ook toe en dat heet T-SQL.

- MySQL is vrij losjes, als je een string van 30 karakters in een veld van 20 lang probeert te proppen, gooit die zelf de laatste 10 karakters wel weg (by default, dit is aan te zetten!).

MySQL houdt er pas een eigen standaard op na

[apokalypse]

MySQL houdt er pas een eigen standaard op na

En als je een transactie vergeet te committen/rollbacken, en je start een nieuwe transactie wordt de oude automatisch gecommit. Hoe handig!

IMO is MySQL prima voor simpele websites. Daarbuiten niet. MSSQL werkt super goed met .Net, maar hoe dat zit met Android e.d. is de vraag. PostgreSQL geen ervaring mee, FireBird bestaat dat nog?

[Sebazzz]

apokalypse schreef op donderdag 19 augustus 2010 @ 22:57:
[...]

IMO is MySQL prima voor simpele websites. Daarbuiten niet. MSSQL werkt super goed met .Net, maar hoe dat zit met Android e.d. is de vraag. PostgreSQL geen ervaring mee, FireBird bestaat dat nog?

Meestal communiceer je via een webservice met de database, niet direct.

[boe2]

Sebazzz schreef op donderdag 19 augustus 2010 @ 23:01:
[...]

Meestal communiceer je via een webservice met de database, niet direct.

Dit dus, het lijkt me niet echt practisch als je DB wachtwoord in je applicatie verwerkt zit en vanaf je telefoon verzonden wordt

[Wirf]

de perfecte DB bestaat niet. Ik heb bijvoorbeeld Oracle en SQLite gebruikt, en voor de situaties waarvoor ik die heb gebruikt waren ze het beste, maar als je deze twee databases zou ruilen in de situatie waar ze gebruikt zouden worden, dan zou het uitlopen op een ramp. (dus bijvoorbeeld Geo-spatial queries met SQLite en Oracle meeleveren met een gratis product)

Dus kijk eerst wat je project nodig heeft, en kies daar de database op uit.
_{Blijf alleen weg bij MySQL, dat is geen database, maar een plek waar bits heengaan om te sterven}

[Wirf]

Boeboe schreef op donderdag 19 augustus 2010 @ 23:05:
[...]


Dit dus, het lijkt me niet echt practisch als je DB wachtwoord in je applicatie verwerkt zit en vanaf je telefoon verzonden wordt

Android heeft een ingebakken SQLite database die je zou kunnen gebruiken.

[Sebazzz]

Wirf schreef op donderdag 19 augustus 2010 @ 23:23:
[...]

Android heeft een ingebakken SQLite database die je zou kunnen gebruiken.

Die kan je als cache gebruiken maar uiteindelijk moet je toch synchroniseren. Van wat ik lees is hier de bedoeling om met een online database te werken.

[Alex)]

Als je veel .NET-based ontwikkeling doet is Microsoft's SQL Server daar in principe de logische aansluiting op, en ook vanuit PHP (i.i.g. op Windows) kun je deze gebruiken. Als je een beetje rondkijkt zul je snel genoeg zien waarom MySQL niet zo'n sterk alternatief is.

Voor het ontsluiten van je data zul je toch een webservice-achtig systeem moeten maken. Je wilt niet je hele database toegankelijk maken voor het wereldwijde web, en ook je credentials wil je niet hardcoded in een applicatie hebben staan. Android hoef je dus eigenlijk niet meer mee te rekenen in je lijstje.

[Freeaqingme]

Wat de 'losjesheid' van MySql betreft, dit is natuurlijk ieaal voor noobs, 'want' alles werkt zonder klagen. Of dat slim is van Mr. Monty laat ik in 't midden. Wel heeft MySql een Strict Mode waarbij de bovengenoemde punten voor een groot gedeelte overkomen kunnen worden. In MariaDb (en naar ik neem aan mysql 5.5) kan je iedere gebruiker een bepaalde hoeveelheid cputijd toekennen. Wat je kan doen als je het gaat deployen mobiele apparaten (a la Andraid) is iedere app-installatie een mysql username/password toekennen, inclusief een hoeveelheid cputijd. Als een gebruiker dan zijn cputijd verbruikt heeft, kan ie meteen een nieuw pakketje cputijd kopen. Wacht, dat bestaat al. Heet The Cloud.

Edit: bovenstaande is wellicht niet helemaal in lijn met TS... sorry!

[sig69]

Als ik je TS zo lees zijn jullie erg Windows en Microsoft minded, en dan ligt MSSQL eigenlijk erg voor de hand. Het werkt prima samen met Visual Studio, (ASP).Net, SilverLight etc. MySQL heb ik ook mee gewerkt en dat vind ik vaak toch "net niet". Alles voelt net wat minder robuust aan vind ik. Postgres en Firebird heb ik geen ervaring mee, aangezien wij alleen .Net ontwikkeling doen en MSSQL dus eigenlijk standaard is.

[Freeaqingme]

sig69 schreef op vrijdag 20 augustus 2010 @ 01:27:
MySQL heb ik ook mee gewerkt en dat vind ik vaak toch "net niet". Alles voelt net wat minder robuust aan vind ik

Kan je dat wat concreter maken (niet dat ik je niet geloof, maar ben wel benieuwd)? Ik heb 1 keer mssql gebruikt, in combinatie met php+windows+iis (voor school), en dat was ergenis na ergenis, maar dat kan er natuurlijk ook mee te maken hebben dat ik normaal gesproken alleen mysql gebruik.

[jbdeiman]

Boeboe schreef op donderdag 19 augustus 2010 @ 23:05:
[...]


Dit dus, het lijkt me niet echt practisch als je DB wachtwoord in je applicatie verwerkt zit en vanaf je telefoon verzonden wordt

Het idee van een webservice waar de db van gebruikt wordt is dat je dus niet een wachtwoord in je programma hackt, maar via de webservice een verzoek doet om bepaalde gegevens terug te krijgen.
Als je dan offline nog een synchronisatie_db hebt staan bij gebruikers van de applicatie, dan doet die eerst een request om te kijken of de data recent is, zo niet->update request, zo wel, haal uit de offline database de gegevens. Op zich niet eens zo lastig te bouwen op zo'n manier.

Maar het gaat hier dus om welke database (die kan communiceren met .NET) de beste keuze is.

freakingme schreef op vrijdag 20 augustus 2010 @ 01:38:
[...]


Kan je dat wat concreter maken (niet dat ik je niet geloof, maar ben wel benieuwd)? Ik heb 1 keer msssql gebruikt, in combinatie met php+windows+iis (voor school), en dat was ergernis na ergernis, maar dat kan er natuurlijk ook mee te maken hebben dat ik normaal gesproken alleen mysql gebruik.

Dat komt waarschijnlijk omdat je vooral MySQL gewend bent. MSSQL en MySQL hebben een andere manier van query'en en ook een aantal verschillende datatypen. Hierdoor is het soms lastig om goede query's te kunnen schrijven.
Wat mij wel opvalt bij MSSQL vs MySQL is dat MySQL meer overeenkomt qua query opbouw en datastructuren (datatypen e.d.) met OracleSQL (de omgeving waarop ik SQL heb geleerd) dan MSSQL.

Zoals ik in mijn eerdere post al aangaf houdt MS er vaak toch deels zijn eigen standaard op na.

[ Voor 36% gewijzigd door jbdeiman op 20-08-2010 06:53 ]

[giMoz]

jbdeiman schreef op vrijdag 20 augustus 2010 @ 06:47:
Zoals ik in mijn eerdere post al aangaf houdt MS er vaak toch deels zijn eigen standaard op na.

Eigen standaard? De standaard die Sybase ontwikkeld heeft voordat MS zich in de database wereld begaf.

OT: elk DBMS heeft z'n quircks:
MSSQL heeft T-SQL
MySQL is genoeg over gezegd
Oracle is de plek waar bitjes niet heengaan om te sterven maar om de rest van hun leven gevangen te zitten met een hele rare set regels die niemand snapt behalve een groep net zo onbegrijpelijke DBA'ers ;-)

Als je veel .NET doet is MSSQL handig, daar is veel voor e.d. MSSQL is ook nog eens relatief makkeiljk te beheren en heeft goede intergratie met tools. (VS, maar ook de eigen enterprise manager is erg goed)

En idd voor applicaties op android moet je toch webservices gebruiken om de database te benaderen.

[PolarBear]

freakingme schreef op vrijdag 20 augustus 2010 @ 01:38:
[...]


Kan je dat wat concreter maken (niet dat ik je niet geloof, maar ben wel benieuwd)? Ik heb 1 keer mssql gebruikt, in combinatie met php+windows+iis (voor school), en dat was ergenis na ergenis, maar dat kan er natuurlijk ook mee te maken hebben dat ik normaal gesproken alleen mysql gebruik.

Sorry maar MS SQL werkt prima icm PHP en IIS, denk dat het meer een kennis gebrek aan jouw kant is. Feit is en blijft dat MySQL (al is het nog zoveel gebruikt) heel rare problemen heeft en had (bijvoorbeeld een Group By doen zonder alle niet geagregeerde members in de select mee te nemen, zal vast een optie voor zijn maar een WTF in DB land). PostgresSQL, MS SQL en Oracle zijn qua DBMS de serieuze spelers. Feit dat bijvoorbeeld MySQL nog geen volledige ondersteuning heeft voor Unicode of dat de 'ACIDheid' afhangt van de gekozen engine zal je bij die 3 DBMSen niet hebben.

jbdeiman schreef op vrijdag 20 augustus 2010 @ 06:47:

Zoals ik in mijn eerdere post al aangaf houdt MS er vaak toch deels zijn eigen standaard op na.

Doet Oracle ook, weet niet precies waar je naar toe wil door te roepen dat MS zijn eigen standaarden heeft. Niemand ondersteund 100% ANSI SQL. Wat fijn is van MS SQL tov bijvoorbeeld Oracle is dat ik met men SQL licentie een heel suite aan tooling krijg. Beheertooling als de SQL Managmentstudio, maar ook Reporting Services, Integration Services en Analysis Services.

Gezien de ontwikkelomgeving van de TS lijkt MS SQL mij een no brainer.

[Snake]

Om nog even eentje af te raden: Oracle. Waarom? Geen auto increment. Dat wil zeggen dat je voor je 20 tabellen 20 apparte sequences mag gaan schrijven.

Hoe idioot kan een database zijn? Je moet bij Oracle gewoon via tooling connecten en die de sequence laten genereren, anders wordt het echt een zootje.

Voor de rest volg ik mijn voorgangers

[Wirf]

Snake schreef op vrijdag 20 augustus 2010 @ 07:31:
Om nog even eentje af te raden: Oracle. Waarom? Geen auto increment. Dat wil zeggen dat je voor je 20 tabellen 20 apparte sequences mag gaan schrijven.

Je kan ook gewoon 1 sequence gebruiken voor de hele database hoor

Om een database af te schieten omdat ze een wat lastige manier hebben voor het genereren van een ID vind ik wat kort door de bocht. Oracle heeft ook zijn sterke punten (geo-spatial, uitgebreide tooling, groot aantal DBA'ers beschikbaar die de programmeurs en hun wilde ideeen nog een beetje in bedwang houden etc.)

[Niemand_Anders]

Snake schreef op vrijdag 20 augustus 2010 @ 07:31:
Om nog even eentje af te raden: Oracle. Waarom? Geen auto increment. Dat wil zeggen dat je voor je 20 tabellen 20 apparte sequences mag gaan schrijven.

Hoe idioot kan een database zijn? Je moet bij Oracle gewoon via tooling connecten en die de sequence laten genereren, anders wordt het echt een zootje.

Het heeft ook voordelen. Heb je ooit weleens meerdere databases (zoals productie records terug kopiëren naar een test omgeving om beter te kunnen testen) gesynchroniseerd. Zo'n actie maakt de auto nummering vrijwel altijd kapot en wordt het hoogste id als je nummer sequence gebruikt.

Bij Oracle, maar PostgreSQL, kun je de sequence op de default constraint zetten waardoor je sequence buiten je tabel vormt. Bij betaalde databases gaat mijn keuze eigenlijk altijd naar MySQL. De processor licenties zijn betaalbaar en per fysieke core en niet zoals bij Oracle en IBM per core met een mutiplier..
Daarnaast is de database package van Microsoft de meeste complete in de markt.

Bij open-source gaat mijn keuze naar PostgreSQL. Voor embedded databases gebruik ik meestal FirebirdSql. Bij enkele zwaardere desktop applicaties heb ik de keuze voor MSSQL Express 2008 gemaakt.

Ik denk niet dat er een 'beste' database bestaat. Elke situatie vraagt om zijn eigen type database en de beste keuze is degene waarbij zowel de developers maar ook de beheerders zich het prettigst voelen.

[RobIII]

Niemand_Anders schreef op vrijdag 20 augustus 2010 @ 08:58:
Bij betaalde databases gaat mijn keuze eigenlijk altijd naar MySQL.

Ik neem aan dat je MSSQL bedoelt?

Als je veel met .NET doet kan ik me alleen maar aansluiten bij de rest: MSSQL. SSMS (voorhéén Enterprise manager) is, vergeleken bij de andere tooling, wel een toppertje evenals de integratie met VS. Qua betrouwbaarheid en onderhoudbaarheid moet ik ze nog beter tegenkomen en qua replicatie zit je al helemaal goed (als in: easy om op te zetten en werkt ook gewoon goed en betrouwbaar). Hou er wél rekening mee dat, AFAIK althans, MSSQL Express (de gratis variant) enkel een subscriber kan zijn en geen publisher. Verder zal in veel "kleine" situaties MSSQL Express al voldoen.

[ Voor 62% gewijzigd door RobIII op 20-08-2010 09:13 ]

[cariolive23]

Binnen onze organisatie hebben we een groep developers die zweren bij MSSQL, Postgre, MySql en Firebird.

Dan zijn er dus eigenlijk 2 groepen: De mensen met ervaring met MS SQL, PostgreSQL en Firebird en dan nog de groep met MySQL-ervaring.

MS SQL, PostgreSQL en Firebird lijken wat gedrag betreft sterk op elkaar, MS SQL en PostgreSQL zijn zelfs verre familie van elkaar (vanuit het project Ingres). PostgreSQL en Firebird maken beiden gebruik van MVCC, dus ook dat is dan een bekend verhaal. Replicatie zit standaard in MS SQL (welke licentie je daarvoor nodig hebt, is mij onbekend), PostgreSQL krijgt met versie 9.0 (release eind deze maand) ingebouwde replicatie en heeft met Slony al jaren replicatiemogelijkheden. Voor Firebird zul je externe tools moeten inzetten wanneer je replicatie nodig hebt, ik heb hier geen ervaring mee.

Met MS SQL heb je geen andere keuze dan een Windows platform, met PostgreSQL en Firebird kun je zo'n beetje ieder OS gebruiken. Tevens zijn PostgreSQL en Firebird open source, wat weer scheelt in licentiekosten. PostgreSQL heeft een zeer vrije licentie, BSD-vorm, de Firebird licentie is mij niet helemaal duidelijk, zul je zelf even moeten doornemen.

En dan MySQL... Dat is een totaal ander ding die zich (zeker in standaard configuratie) totaal anders gedraagt dan wat je van een (R-) DBMS zou mogen verwachten. En dan hou ik het netjes.

Mijn keuze: PostgreSQL. Zeer betrouwbaar (is altijd prio 1), snel, eenvoudig in gebruik, uitstekende community en goedkoop.

[DigiK-oz]

Ik zou eerst eens gaan vragen WAAROM de developpers zweren bij een bepaalde database. Benieuwd wat voor antwoorden je krijgt. Ik denk dat het meestal zo is dat de ene developper "het vak geleerd heeft" met database X, en zich nooit heeft verdiept in de rest.

Dat een DBA een voorkeur heeft geloof ik, maar een developper zou het ober het algemeen toch moeten jeuken? De gemiddelde select/insert/update statements zijn heus wel in alle RDBMS-systemen mogelijk. En vaak wordt er gewerkt met een O/R mapper, die toch ook meestal wel meerdere databases ondersteunen.

Een "beste" database is er niet denk ik, maar wel een "slechtste", en dat is een (groot) aantal verschillende . Je hebt voor beheer (DBA) dan verschillende mensen nodig (of eentje die al die databases écht kent, maar die zijn zeldzaam), en standaarden opzetten wordt ook verdacht lastig.

Ik zou er, op basis van input van de developpers én DBA(s) ééntje kiezen (en gezien het grote aandeel .NET in je software ligt MSSQL inderdaad voor de hand), en als een developper zegt dat zijn applicatie daar niet mee kan werken mag hij verklaren waarom dat zo is, en samen met de DBA naar een oplossing zoeken.

[RobIII]

DigiK-oz schreef op vrijdag 20 augustus 2010 @ 09:19:
Dat een DBA een voorkeur heeft geloof ik, maar een developper zou het ober het algemeen toch moeten jeuken?

In a perfect world misschien. In veel bedrijven mag je al blij zijn als er een systeembeheerder is, laat staan een DBA'er. En als developer heb je net zo goed te maken met tooling en zaken die je in een (ontwikkel)DB moet gaan zitten rommelen zonder tussenkomst van een (want: niet bestaande) DBA'er. En als developer heb je ook erg veel aan integratie in je ontwikkelomgeving en is het wel héél fijn als zaken gewoon goed/lekker op elkaar aansluiten/inhaken. Met VS->MySQL bijvoorbeeld is dat gewoon, ondanks dat het niet zo hoeft te zijn, niet zo lekker als met VS->MSSQL.

DigiK-oz schreef op vrijdag 20 augustus 2010 @ 09:19:
Ik denk dat het meestal zo is dat de ene developper "het vak geleerd heeft" met database X, en zich nooit heeft verdiept in de rest.

Het klinkt misschien vreemd, maar ik heb het idee dat 't vooral bij "MySQL-ers" is. Die beginnen vaak daar mee en blijven er dan bij. Mensen die met PosteGre, Firebird, Oracle of MSSQL in aanraking zijn geweest zijn vaak al wat breder georiënteerd. En vaak zijn die wat meer "verwend" en zullen dus wel al met andere RDBMS-en ervaring hebben en dan al gauw (terug) neigen naar het RDBMS dat naar hun idee het best is; iemand die MSSQL kan gebruiken zal niet snel naar MySQL "terug vallen". Maar dat kan ook te maken hebben met de hoge(re) dichtheid "thuisdevvers" die vaak met een LAMP zitten stoeien en dit is puur een subjectieve (en wellicht biased) ervaring die ik heb.

[ Voor 36% gewijzigd door RobIII op 20-08-2010 09:27 ]

[Remus]

cariolive23 schreef op vrijdag 20 augustus 2010 @ 09:09:
[...]

Met MS SQL heb je geen andere keuze dan een Windows platform, met PostgreSQL en Firebird kun je zo'n beetje ieder OS gebruiken. Tevens zijn PostgreSQL en Firebird open source, wat weer scheelt in licentiekosten. PostgreSQL heeft een zeer vrije licentie, BSD-vorm, de Firebird licentie is mij niet helemaal duidelijk, zul je zelf even moeten doornemen.

De Firebird licentie valt onder InterBase Public Licence (oorspronkelijke release van de InterBase code door Borland), nieuwe code valt onder de Initial Developer's Public License. Beide zijn een variant van de Mozilla Public Licence ("The MPL is characterized as a hybridization of the modified BSD license and GNU General Public License")

[Hydra]

freakingme schreef op vrijdag 20 augustus 2010 @ 01:38:
Kan je dat wat concreter maken (niet dat ik je niet geloof, maar ben wel benieuwd)? Ik heb 1 keer mssql gebruikt, in combinatie met php+windows+iis (voor school), en dat was ergenis na ergenis, maar dat kan er natuurlijk ook mee te maken hebben dat ik normaal gesproken alleen mysql gebruik.

Dat ligt dan aan jezelf. Wij moeten onze software integreren met een heel scala aan databases (hebben daar een eigen Java ETL tool voor ontwikkeld die een relationeel datamodel op ons eigen 'OO' datamodel mapped) en kwa beheer en easy of use heb ik toch een grote voorkeur voor MSSQL t.o.v. Ingres, DB2, Oracle en MySQL (terwijl ik met die laatste al sinds m'n studie werk).

Wirf schreef op vrijdag 20 augustus 2010 @ 07:46:
Om een database af te schieten omdat ze een wat lastige manier hebben voor het genereren van een ID vind ik wat kort door de bocht. Oracle heeft ook zijn sterke punten (geo-spatial, uitgebreide tooling, groot aantal DBA'ers beschikbaar die de programmeurs en hun wilde ideeen nog een beetje in bedwang houden etc.)

Breek me de bek niet open over Oracle DBA's...

RobIII schreef op vrijdag 20 augustus 2010 @ 09:22:
In a perfect world misschien. In veel bedrijven mag je al blij zijn als er een systeembeheerder is, laat staan een DBA'er. En als developer heb je net zo goed te maken met tooling en zaken die je in een (ontwikkel)DB moet gaan zitten rommelen zonder tussenkomst van een (want: niet bestaande) DBA'er. En als developer heb je ook erg veel aan integratie in je ontwikkelomgeving en is het wel héél fijn als zaken gewoon goed/lekker op elkaar aansluiten/inhaken. Met VS->MySQL bijvoorbeeld is dat gewoon, ondanks dat het niet zo hoeft te zijn, niet zo lekker als met VS->MSSQL.

Inderdaad. In ons bedrijf hebben we sowieso geen keuze; het ligt maar net aan wat er bij een nieuwe klant draait, daar moeten we dan maar mee integreren. En zolang er een JDBC driver voor is, is dat op zich geen probleem. Maar als iemand mij zou vragen welke RDBMS ik aan zou raden, zou dat MSSQL zijn, hoewel ik vroegah thuis ook 'fijn' met een WAMP setup knutselde.

[ Voor 29% gewijzigd door Hydra op 20-08-2010 10:29 ]

[DigiK-oz]

RobIII schreef op vrijdag 20 augustus 2010 @ 09:22:
[...]
In a perfect world misschien. In veel bedrijven mag je al blij zijn als er een systeembeheerder is, laat staan een DBA'er. En als developer heb je net zo goed te maken met tooling en zaken die je in een (ontwikkel)DB moet gaan zitten rommelen zonder tussenkomst van een (want: niet bestaande) DBA'er.

Tja, dan ligt het misschien anders. Aan de andere kant, ook als je geen DBA aan boord hebt, wil je denk ik toch voor één database kiezen. Dan kunnen devvers elkaars werk overnemen zonder eerst de quirks van een andere database te hoeven leren. Daarnaast denk ik dat een devver over het algemeen geen goede DBA is en omgekeerd. Idem met devver vs systeembeheerder. Ze weten heus wel iets van elkaars werk (meestal), maar het zijn aparte takken van sport.

Hele kleine berijven daargelaten waar het gewoon niet kan, denk ik dat je dus gewoon een DBA nodig hebt, als een devver "het er even bij doet" komt dat het eindprodukt niet ten goede.

TS wil standaardiseren. Wel of geen DBA, maak een keuze voor één database en wijk daar alleen vanaf als een devver aantoonbaar kan maken dat het niet kán of teveel geld kost. Niet omdat hij het niet wil omdat hij verliefd is op zijn "eigen" RDBMS.

[Hydra]

DigiK-oz schreef op vrijdag 20 augustus 2010 @ 10:27:
Tja, dan ligt het misschien anders. Aan de andere kant, ook als je geen DBA aan boord hebt, wil je denk ik toch voor één database kiezen.

Die optie heb je niet altijd. Maar zoals ik al zei; als ik een keuze zou hebben zou ik voor MSSQL gaan. De beheertools van Oracle zijn verschrikkelijk. En ze zijn al voor een groot deel .Net gebaseerd en het integreren van een MSSQL DB in een .Net WebApp bijvoorbeeld is triviaal.

[ Voor 13% gewijzigd door Hydra op 20-08-2010 10:31 ]

[jbdeiman]

PolarBear schreef op vrijdag 20 augustus 2010 @ 07:16:
[...]

Sorry maar MS SQL werkt prima icm PHP en IIS, denk dat het meer een kennis gebrek aan jouw kant is. Feit is en blijft dat MySQL (al is het nog zoveel gebruikt) heel rare problemen heeft en had (bijvoorbeeld een Group By doen zonder alle niet geagregeerde members in de select mee te nemen, zal vast een optie voor zijn maar een WTF in DB land). PostgresSQL, MS SQL en Oracle zijn qua DBMS de serieuze spelers. Feit dat bijvoorbeeld MySQL nog geen volledige ondersteuning heeft voor Unicode of dat de 'ACIDheid' afhangt van de gekozen engine zal je bij die 3 DBMSen niet hebben.


[...]

Doet Oracle ook, weet niet precies waar je naar toe wil door te roepen dat MS zijn eigen standaarden heeft. Niemand ondersteund 100% ANSI SQL. Wat fijn is van MS SQL tov bijvoorbeeld Oracle is dat ik met men SQL licentie een heel suite aan tooling krijg. Beheertooling als de SQL Managmentstudio, maar ook Reporting Services, Integration Services en Analysis Services.

Gezien de ontwikkelomgeving van de TS lijkt MS SQL mij een no brainer.

Het is misschien niet netjes om te roepen dat MS zijn eigen standaard heeft, maar als je de ene DB gewent bent is het lastig wennen aan een ander. Het gaat ook eigenlijk niet zozeer MS die het "niet goed doet", maar er is blijkbaar niet 1 standaard (qua datasets e.d.) waarmee je alle databases kan werken. Er zijn te veel SQL varianten die elk op een eigen manier werken, en andere data-typen e.d. hebben.

Denk dat het zo netter geformuleerd is.

[Killemov]

Mijn eerste keuze zal altijd postgres zijn.

Er zijn wel degelijk globale standaards voor SQL. De ene RDBMS houdt zich daar beter aan dan andere. PostgreSQL is bijvoorbeeld heel compliant aan de laatste SQL standaard.

Al heeft een groot bedrijf een corporate licentie voor Oracle, als de database niet gekoppeld hoeft te worden aan andere databases, dan toch liever postgres. Ik moet wel zeggen dat de sql-commando's die Oracle bedacht heeft voor het queryen van boomstructuren erg innovatief vind.

[DamadmOO]

DigiK-oz schreef op vrijdag 20 augustus 2010 @ 09:19:
Ik zou eerst eens gaan vragen WAAROM de developpers zweren bij een bepaalde database. Benieuwd wat voor antwoorden je krijgt. Ik denk dat het meestal zo is dat de ene developper "het vak geleerd heeft" met database X, en zich nooit heeft verdiept in de rest.

Hier heb ik toevallig op een conferentie nog een gesprek over gehad met een MSSQL Server MVP en Oracle OCM en we waren het er alle 3 over eens dat het meer de manier van programmeren is. Waar MSSQL extreem snel is in set-based queries en over het algemeen sloom presteerd in row-based (cursor) operaties is het bij Oracle precies andersom. Dus een ontwikkelaar die gewend is om in MSSQL met set-based operaties te beginnen in Oracle krijgt meteen het gevoel dat Oracle traag is, terwijl hij eigenlijk moet leren om row-based te programmeren (en dat is dus ook zo als een Oracle ontwikkelaar overstapt naar MSSQL).

Wat nu de beste database engine is, is erg afhankelijk van het gebruik. Voor een "gewone" OLTP database maakt het eigenlijk niet uit (zolang de specifieke eigenschappen van elke engine goed gebruikt worden), maar binnen de OLAP wereld is MSSQL sinds de release van 2008 (en speciaal nu met 2008 R2) eigenlijk de standaard. Dit komt deels door SSIS (SQL Server Integration Services), maar ook door het licentie model van MSSQL. Ik zit nu zelf in een project waar een bedrijf wat alles op Oracle heeft draaien hun BI platform overzet naar MSSQL.

Voor de DBA rol ga ik toch in de richting van MSSQL, maar dat komt voornamelijk doordat ik daar meer ervaring mee heb (en MSSQL DBA-ers zijn minder eigenwijs dan Oracle DBA-ers )

Note: MSSQL heeft sinds de release van 2008 ook ondersteuning voor geo-spatial en hierarchien,

[Verwijderd]

Tweakerts,

Even wat opheldering (ik ken de TS). Het gaat ons vooral om de replicatie.
We maken gebruik van DevExpress XAF en moeten dit gaan toepassen in combinatie met multimaster replicatie.

De applicatie draaid op diverse terminals die een subset van de gegevens muteren (insert/update paar tabellen) en een subset van de gegevens moeten kunnen inspecteren (nog wat meer tabellen). Dan zijn er workstations die zo'n beetje alles moeten kunnen muteren en inspecteren. Dit verspreid over meerdere locaties (geografisch), verbonden met VPN over breedband. Een eerste stap is het geheel al op een enkele locatie te laten functioneren.

Op de "grens" tussen geografische gebieden kunnen we WCF inzetten (gaat maar een kleine hoeveelheid van de domein objecten die tussen locaties beschikbaar moeten zijn). Dit hebben we al eerder gedaan voor bestaande software en dat werkt goed.

Het is alleen redelijk bewerkelijk om alle data in een enkele locatie tussen elk apparaat / server te synchroniseren met WCF services (veel code schrijven, haalt het hele voordeel van XAF weg). Het probleem is namelijk dat terminals zelfstandig door moeten gaan als de verbinding met de server vervalt (en dus allemaal een eigen database hebben). Het schrijven van services om ál die data te synchroniseren tussen de apparaten in één locatie is gewoon te veel werk dus komen we uit bij een DBMS met multi-master replicatie (elk apparaat kan in princiepe publisher zijn, bepaalde apparaten meer dan andere zeg maar... ;-)) (weet niet of mijn terminologie overal correct is, ben geen DBMS expert).

Licenties zijn het probleem niet. Momenteel zetten we MS SQL in (zijn nog aan het experimenteren met de replicatie). PostgreSQL leek mij ook een leuke optie maar wat ik tot nu toe gezien heb lijkt het mij meer werk om PostgreSQL goed aan de gang te krijgen. In MS SQL noemen ze wat wij nodig hebben merge replication maar volgens mij krijg ik dan problemen met MS SQL Express (zal wel niet in dat plaatje passen, iemand ervaring??). Om voor elke terminal een licentie te kopen is dan net iets aan de dure kant ;-).

[cariolive23]

Verwijderd schreef op zaterdag 21 augustus 2010 @ 16:36:
PostgreSQL leek mij ook een leuke optie maar wat ik tot nu toe gezien heb lijkt het mij meer werk om PostgreSQL goed aan de gang te krijgen.

Nou, wat zal het zijn, 4x klikken op Ok bij het installeren? Het configuratiebestand mag je nog even even iets aanpassen wanneer je meer geheugen wilt toekennen aan PostgreSQL, maar ook dat is geen rocketscience. Mocht je een installer schrijven voor de installatie van jouw programma en de database, kun je ook dit soort dingen direct door de installer laten doen, werkt uitstekend. Dan kun je de 4x klikken op Ok ook overslaan...

Voor multimaster replicatie zul je met PostgreSQL externe tools moeten inzetten, maar dat zul je met SQL Server Express ook moeten doen.

[Killemov]

Als je kijkt naar Wikipedia: Multi-master replication zie je dat MSSQL daar iig niet bij staat. Maar goed dit gaat nog over replicatie tussen servers onderling. Als je iets met Android wil, dan gaat dat verheel helemaal niet op en zul je hoogstwaarschijnlijk toch iets zelf moeten maken. Misschien heeft Google voor Android wel iets moois bedacht. Zoek daar eerst eens naar.

[DamadmOO]

Ook al staat MSSQL niet in de lijst heeft het wel de mogelijkheid (merge replication), maar net zoals met al deze soort van opzetten is het niet makkelijk om de data weer te syncen nadat een database voor een lange periode offline is geweest.

[ACM]

Wat een gezeik op MySQL hier. Het heeft zeker zo zijn quircks, maar het is tegelijkertijd onzin om net te doen of het geen echte database is. Zeker de laatste incarnaties (5.0+) zijn lang niet zo gek/slecht als hier in korte zinnetjes gesuggereerd wordt. Ik heb de indruk dat de meesten punten uit de 3.x-tijd hebben onthouden en die onverkort nu herhalen.
Als we dan werkelijk op die fiets willen: PostgreSQL is instabiel (in de pre-7.0-tijd was het instabieler dan de toen beschikbare mysql) en kent een krappe 8KB row-size limiet (pre-7.1). Sterker nog, vziw zijn dat RedHat destijds PostgreSQL niet meer zo nadrukkelijk als hun primair geinstalleerde database ging vertonen. Ironisch genoeg is de stabiliteit van PostgreSQL nu een van de pluspunten

Het hangt natuurlijk allemaal van de te ontwikkelen toepassingen af, maar zeker voor web-toepassingen zou MySQL wel degelijk op de short-list mogen staan.

[cariolive23]

ACM schreef op zondag 29 augustus 2010 @ 22:40:
Het hangt natuurlijk allemaal van de te ontwikkelen toepassingen af, maar zeker voor web-toepassingen zou MySQL wel degelijk op de short-list mogen staan.

Alleen jammer dat er vanaf 31 december dit jaar geen active support meer is voor MySQL... Geen enkele GA-versie die op dit moment beschikbaar is, en dat is alleen versie 5.1, heeft na 31-12-2010 nog active support. Over 4 maanden is het dus over en uit met de pret:

http://www.mysql.com/about/legal/lifecycle/#calendar
GA Version GA Date Active Support Ends
5.1 2008-12-08 2010-12-31

Er wordt gewerkt aan de versies 5.5 en 5.6, maar beiden zijn nog in alpha of beta stadium en géén GA en dus niet bruikbaar voor productieomgevingen. Wanneer deze versies beschikbaar komen, is onbekend.

PostgreSQL heeft op dit moment diverse GA versies, 8.1, 8.2, 8.3 en 8.4. Iedere versie wordt 5 jaar ondersteund, support voor 8.1 eindigt dit jaar, support voor 8.4 eindigt in 2014. De volgende GA versie van PostgreSQL, versie 9.0, komt over een week of 2, 3 beschikbaar, deze zal dus tot 2015 worden ondersteund. De RC komt vandaag of morgen beschikbaar, de beta's liggen al weer achter ons.

Dus, wil je zekerheid over support en dus patches, dan zul je hier rekening mee moeten houden.

[Wirf]

ACM schreef op zondag 29 augustus 2010 @ 22:40:
Wat een gezeik op MySQL hier. Het heeft zeker zo zijn quircks, maar het is tegelijkertijd onzin om net te doen of het geen echte database is. Zeker de laatste incarnaties (5.0+) zijn lang niet zo gek/slecht als hier in korte zinnetjes gesuggereerd wordt. Ik heb de indruk dat de meesten punten uit de 3.x-tijd hebben onthouden en die onverkort nu herhalen.

Ik geef toe dat mijn ervaring met MySQL al weer een poos geleden is. Hebben ze onderhand die bug al opgelost dat als te lange tekst insert, dat dan gewoon de tekst getruncate wordt en zonder te morren opgeslagen wordt?

Dat is voor mij namelijk echt een doodzonde voor een database; een database moet voor mij of alles opslaan, of helemaal niets. Alles er tussenin is een bug.

[Zoijar]

Ik zou toch voor PostgreSQL gaan, simpelweg om de uitgebreide functionaliteit, standard compliance, goede performance en gratis. Verder is het nog open source, dus je zou altijd iets aan kunnen passen als het echt nodig is en er zijn zat extensions beschikbaar (PostGIS bv.). Zie niet in waarom je duizenden (6k per processor?) voor MSSQL zou betalen.

[cariolive23]

@wirf: Zie de SQL_MODES die MySQL kent, standaard wordt iedere fout onder het tapijt geveegd. Dit kun je (helaas) per connectie instellen en dus goed of fout doen... Integriteit heeft niet de hoogste prioriteit bij MySQL, nog steeds niet.

[Janoz]

Wirf schreef op maandag 30 augustus 2010 @ 10:22:
...Een database moet voor mij of alles opslaan, of helemaal niets...

Ik heb het liefst wel dat ik een melding krijg in het tweede geval

[Verwijderd]

Ik zit ongeveer met hetzelfde probleem als de TS. Uit bovenstaande reacties heb ik besloten voor PostgresSQL te kiezen. Ik ontwikkel in VB.NET, maar vanaf volgend schooljaar zal dit ook Java worden. Nu had ik graag geweten welke connector ik moet gebruiken.

[cariolive23]

Verwijderd schreef op dinsdag 31 augustus 2010 @ 16:51:
Ik zit ongeveer met hetzelfde probleem als de TS. Uit bovenstaande reacties heb ik besloten voor PostgresSQL te kiezen. Ik ontwikkel in VB.NET, maar vanaf volgend schooljaar zal dit ook Java worden. Nu had ik graag geweten welke connector ik moet gebruiken.

JDBC? Ligt voor de hand Verder wordt er vaak Hibernate gebruikt, doet zijn werk ook via JDBC. Voor .NET heb je NHibernate.

[ Voor 3% gewijzigd door cariolive23 op 31-08-2010 17:40 . Reden: Linkje naar de jdbc driver voor PostgreSQL toegevoegd ]

[Verwijderd]

cariolive23 schreef op dinsdag 31 augustus 2010 @ 17:35:
[...]

JDBC? Ligt voor de hand Verder wordt er vaak Hibernate gebruikt, doet zijn werk ook via JDBC. Voor .NET heb je NHibernate.

Werkt JDBC zowel met .NET als met Java?

[cariolive23]

Wanneer je direct vanuit .NET met PostgreSQL wilt werken, heb je Npgsql tot je beschikking. NHibernate maakt hier ook gebruik van.

[Sebazzz]

Verwijderd schreef op dinsdag 31 augustus 2010 @ 17:43:
[...]


Werkt JDBC zowel met .NET als met Java?

Java Database Connectivity? Wat denk je zelf
Java werkt via JDBC met ODBC, en .NET kan er direct mee werken. Overigens is een library native voor je programmeeromgeving het beste meestal.

[Wolfboy]

Zoijar schreef op maandag 30 augustus 2010 @ 10:23:
Ik zou toch voor PostgreSQL gaan, simpelweg om de uitgebreide functionaliteit, standard compliance, goede performance en gratis. Verder is het nog open source, dus je zou altijd iets aan kunnen passen als het echt nodig is en er zijn zat extensions beschikbaar (PostGIS bv.). Zie niet in waarom je duizenden (6k per processor?) voor MSSQL zou betalen.

MSSQL bied ook wel wat meerwaarde voor die duizenden. Een mooie grafische ontwikkelomgeving voor queries, tabellen en meer. Een automatische optimizer (al ben ik zelf nogal huiverig voor dergelijke tools). Of het de prijs verantwoord weet ik niet, maar er is iets voor te zeggen

Al gaat persoonlijk mijn voorkeur toch ook uit naar Postgres. Kan alles wat ik nodig heb en de rest is er vrij eenvoudig bij de scripten in plpgsql, c, java, python, perl, etc... ideaal

[Creepy]

Even dicht ter onderhoud....

En weer open. Even wat zaken afgesplitst naar Database keuze i.v.m. performance

[ Voor 65% gewijzigd door Creepy op 13-09-2010 15:20 ]

[Killemov]

Wirf schreef op maandag 30 augustus 2010 @ 10:22:
Dat is voor mij namelijk echt een doodzonde voor een database; een database moet voor mij of alles opslaan, of helemaal niets. Alles er tussenin is een bug.

Precies, keihard borken die query.

ACM schreef op zondag 29 augustus 2010 @ 22:40:
Wat een gezeik op MySQL hier. Het heeft zeker zo zijn quircks, maar het is tegelijkertijd onzin om net te doen of het geen echte database is. Zeker de laatste incarnaties (5.0+) zijn lang niet zo gek/slecht als hier in korte zinnetjes gesuggereerd wordt. Ik heb de indruk dat de meesten punten uit de 3.x-tijd hebben onthouden en die onverkort nu herhalen.
Als we dan werkelijk op die fiets willen: PostgreSQL is instabiel (in de pre-7.0-tijd was het instabieler dan de toen beschikbare mysql) en kent een krappe 8KB row-size limiet (pre-7.1). Sterker nog, vziw zijn dat RedHat destijds PostgreSQL niet meer zo nadrukkelijk als hun primair geinstalleerde database ging vertonen. Ironisch genoeg is de stabiliteit van PostgreSQL nu een van de pluspunten

Het hangt natuurlijk allemaal van de te ontwikkelen toepassingen af, maar zeker voor web-toepassingen zou MySQL wel degelijk op de short-list mogen staan.

MySQL is echt lange tijd een k*tprodukt geweest. Database-integriteit in clientcode bewaken? Nuff said. Eigenlijk niet veel meer dan een verzameling losse tabellen dus. Het enige interessante ding aan MySQL was het pluggable engine concept.

Ik ben echt al HEEEEEL lang met postgres aan de slag (6.X). En stabiliteits-issues hebben eigenlijk alleen in echt nieuwe features gezeten. Daarnaast heb ik met andere dbms-sen gewerkt waar Michael Stonebraker aan de wieg heeft gestaan. (Ingres, Informix) Ook stuk voor stuk stabiele produkten.

cariolive23 schreef op dinsdag 31 augustus 2010 @ 17:47:
Wanneer je direct vanuit .NET met PostgreSQL wilt werken, heb je Npgsql tot je beschikking. NHibernate maakt hier ook gebruik van.

Kijk ook eens naar NDO. Met java werk ik liever met een Datanucleus (JDO implementatie) dan met Hibernate. Al moet ik wel zeggen dat de compile-time enhancement de doorslag heeft gegeven. En mappen met annotations ipv XML.

[Freeaqingme]

Killemov schreef op woensdag 15 september 2010 @ 13:45:

MySQL is echt lange tijd een k*tprodukt geweest.

Dat ontkent toch ook niemand? Alleen is het niet zo zinvol te blijven roepen hoe slecht het een paar jaar geleden was.

[MueR]

Killemov schreef op woensdag 15 september 2010 @ 13:45:
Precies, keihard borken die query.

http://dev.mysql.com/doc/...error_warn_data_truncated
Als jij gewoon naar de SQL_STATE luistert, kan je er gewoon keihard op borken.

[Wolfboy]

MueR schreef op woensdag 15 september 2010 @ 15:35:
[...]

http://dev.mysql.com/doc/...error_warn_data_truncated
Als jij gewoon naar de SQL_STATE luistert, kan je er gewoon keihard op borken.

En anders zet je gewoon de SQL_MODE op TRADITIONAL. Dan geven dat soort dingen gewoon errors

[MueR]

Bijvoorbeeld. Dergelijke dingen zijn prima in je code af te vangen, of in de server in te stellen. Het kansloze en eeuwige bashen op MySQL wat ACM in "Database keuze" ook al aanhaalde begint echt vervelend te worden.

[Killemov]

Freeaqingme schreef op woensdag 15 september 2010 @ 15:12:
[...]
Dat ontkent toch ook niemand? Alleen is het niet zo zinvol te blijven roepen hoe slecht het een paar jaar geleden was.

Nou, ja zeg ... in de context van de vermeende instabiliteit van oude versies van Postgres toch zeker wel?

Ik ben al lange tijd niet meer bezig met MySQL, maar moet er nog steeds een state worden opgevraagd om achteraf te corrigeren?

[Wolfboy]

MueR schreef op woensdag 15 september 2010 @ 20:23:
Bijvoorbeeld. Dergelijke dingen zijn prima in je code af te vangen, of in de server in te stellen. Het kansloze en eeuwige bashen op MySQL wat ACM in "Database keuze" ook al aanhaalde begint echt vervelend te worden.

Zolang MySQL default gewoon heel erg laks is met de standaarden (i.e. SQL_MODE niet standaard op ANSI | TRADITIONAL) zal je dit gezeur houden.

Het is imho ook erg triest dat MySQL standaard niet default settings naar ACID compliant databases. Prima dat je MyISAM als keuze hebt, maar maak het een geavanceerde optie die mensen met verstand van zaken kunnen gebruiken als ze het nodig.


Voor de rest komt het gezeur imho voornamelijk voort uit verschillende doelen. MySQL heeft maar weinig features als je het vergelijkt met Postgres maar ik denk dat het doel ook wat anders is. MySQL is meer gemaakt voor simpele* databases waar je gewoon data in pompt en eruit trekt zonder dat je geavanceerde dingen als triggers/stored procedures/custom types nodig hebt. De MySQL query planner is naar mijn mening niet heel intelligent maar dat heb je in veel gevallen ook totaal niet nodig.

*met simpel bedoel ik doorsnee tabellen versus tabellen met table inheritance, custom types, stored procedures die grote stukken code uitvoeren, views, etc...
Ik heb het met MySQL al een aantal keren meegemaakt dat complexere queries (joins over aan paar grote tabellen) minuten duurden omdat de query planner geen slim query plan kon gokken. Terwijl postgres het met precies dezelfde tabelstructuur en data binnen een seconde het resultaat gaf.