[Database] Wat is de beste?

[Verwijderd]

Welk is de beste database? Ik heb al een pak gelezen online, maar nog niet echt een deftige vergelijking gevonden, misschien dat gulle meerdere db kennen zodat ik kan vergelijken?

Ze moet draaien op linux, UITERST stabiel zijn, gewoon simpele update/select/insert/delete toestaan. Enorm grote data bewaren + zeer goede indexering hebben voor snelle retreival.

Welke ik na mijn selecties heb overgehouden zijn: Oracle, MySQL & PostgreSQL.


Zijn er die ik nog moet bekijken? Kent er iemand meerdere daarvan & kan die persoon op basis van zijn ervaring mij zeggen welk de betere is van de 2?

[GBits]

Ik zou voor SQL2000 op Windows Server 2003 gaan.
Maar goed, je wil Linux...

modbreak: kun je dit soort offtopic flamebaits de volgende keer thuislaten? dat doe je maar ergens anders

[ Voor 50% gewijzigd door curry684 op 15-06-2003 20:10 ]

[tomato]

Zijn prijs en hosting mogelijkheden ook relevant? Oracle wordt namelijk al snel erg prijzig. MySQL wordt door erg veel hosting providers aangeboden, maar PostgreSQL heeft tegenwoordig bijna alleen nog maar voordelen boven MySQL (kijk daarvoor eens in de sig van ACM).

Lecram schreef op 15 June 2003 @ 18:45:
Ik zou voor SQL2000 op Windows Server 2003 gaan.
Maar goed, je wil Linux...

Lekker nuttige toevoeging. Ten eerste merk je zelf al op dat de dbm op Linux moet draaien, ten tweede geef je nul woorden aan toelichting. Hebben we dus helemaal niets aan.

[Verwijderd]

Je zou verder ook kunnen denken aan bijv Firebird, SapDB en DB2. Verder zijn veel van de online te vinden vergelijkingen tussen DBs niet representatief, en bovendien verouderen ze snel ivm nieuwe versies. Verder speelt persoonlijke voorkeur vaak een grote rol in de argumenten die worden gegeven.

Mijn advies is om te kijken naar een database die goed genoeg is, ook al is die niet persee de beste. Daarmee kan je nauwelijks mis gaan met de commerciele DBs. Verder denk ik dat de anderen ook aan de meeste van jouw eisen voldoen, dus kies wat voor jou het makkelijkst is.

Mijn vraag: wat is "Enorm grote data"? Kijk of je data wel in beschikbare datatypes past, en hoe goed die werken binnen de specifieke DBs.

Edit:
Als het corporate software is, en wellicht bedrijfskritisch, kijk dan ook naar zaken als back up fasciliteiten, beschikbaarheid van tools en commerciele support.

[ Voor 14% gewijzigd door Verwijderd op 15-06-2003 18:57 ]

[Verwijderd]

tomato> mkay, zal eens zien, kosten zijn relevant, maar het is bedrijfsgericht... Dus niet zo echt heel relevant.
Die link van ACM is wel heel interessant... Heb je zo ook iets over de negatieve dingen van andere dabatases? (iets dat niet verouderd is I mean )


mrX> grote data is toch een klein 7k records/dag voor 1 tabel... Dat met een archief van 5 jaar ... Dan komen er nog een stuk of 20 van dat soort tabellen erbij met +- 50k records/dag, archief 2 jaar.

[ Voor 134% gewijzigd door Verwijderd op 15-06-2003 19:03 ]

[ACM]

Verwijderd schreef op 15 juni 2003 @ 18:38:
Welke ik na mijn selecties heb overgehouden zijn: Oracle, MySQL & PostgreSQL.

Op welke basis heb je dit vergeleken

Want waarom staan bijv DB2 en Sybase niet in het lijstje?

Wat zijn je eisen/criteria? Snelle en simpele toegang tot grote datasets?
Wat is voor jou een grote dataset? Hebben we het dan over 100MB, 10GB, 100GB??

Zijn er die ik nog moet bekijken? Kent er iemand meerdere daarvan & kan die persoon op basis van zijn ervaring mij zeggen welk de betere is van de 2?

Ik ken ze alledrie maar heb vrij weinig ervaring met Oracle en relatief veel met mysql en postgresql.

In principe zijn alledrie de databases stabiel, Oracle zou het stabielst moeten zijn, met Postgresql en MySQL vrij dicht erna. Vooral met MySQL heb ik nog wel eens echt rare crashes meegemaakt (een query ala 'delete from tabelletje' waarbij de tabel nogal groot was en de boel gewoon helemaal crashte en niet zomaar opnieuw startte).

Een paar belangrijke dingen waar je rekening mee moet houden:
- Oracle is duur/kost naast het beheer ook geld voor aanschaf/gebruik
- MySQL is alleen snel met echt simpele queries, de queryanalyzer/planner van MySQL is zeer slecht vergeleken met die van Oracle en PostgreSQL maar door de eenvoud wint mysql het bij vrijwel alle echt simpele queries kwa performance.
- PostgreSQL en Oracle worden default vrij krap ingesteld kwa performancesettings, dus op het moment dat je dat installeert en dan denkt "wat is dit traag!" moet je nog aan het werk om de optimale parameters uit te zoeken en niet de standaardsettings gebruiken.

Zoals gezegd, ik weet je criteria niet:
MySQL-innodb draait prima stabiel met een dataset van zo'n 25GB hier op GoT en ik zie op de postgresql mailinglists mensen praten over stabiel draaiende postgresql-servers met datasets over de 60GB.

Maar even puntsgewijs:

Verwijderd schreef op 15 juni 2003 @ 18:38:
Welk is de beste database?

Je criteria zijn niet duidelijk genoeg om daar een antwoord op te geven.

UITERST stabiel zijn

't Is een beetje een troll, maar als je uiterst met hoofdletters moet schrijven, dan moet je geen mysql gebruiken imho. Er zijn mensen die dat niet met mij eens zijn en waarschijnlijk zijn ze dat wel terecht niet met mij eens, magoed

Ik neem echter aan dat je de ACID-eisen gegarandeerd wilt krijgen? MySQL's default install kent geen van de ACID-eisen, pas als je InnoDB gebruikt.
Imho zijn Postgres en Oracle beide beter toegerust om de data _altijd_goed_ op te slaan, ipv zo snel mogelijk op te halen.

gewoon simpele update/select/insert/delete toestaan.

Wat is "gewoon simpel"?
Is dat met subselects, transacties, foreign keys, etc? Of is dat echt alleen maar heel dom "select ... from tabel where ..." ?

Enorm grote data bewaren

Bedoel je grote dataelementen of in totaal veel data? Wat voor records zijn het?

+ zeer goede indexering hebben voor snelle retreival.

Bedoel je ook flexibele index-opties? Dus een functionele index of bitmap index kunnen gebruiken?
Hoe wil je die data ophalen? Denk je dat je queries krijgt die van meerdere indices tegelijk gebruik moeten maken (iets dat mysql niet kan) omdat je er OR's in gebruikt?

[ACM]

Lecram schreef op 15 June 2003 @ 18:45:
Ik zou voor SQL2000 op Windows Server 2003 gaan.
Maar goed, je wil Linux...

Wil je dat soort opmerkingen laten?

't Gaat hier om een goede/de beste oplossing voor een linuxplatform en daar zal de topicstarter goede redenen voor hebben. Als je dan nog de moeite nam de goede punten van SQL2000 af te zetten tegen Oracle, Postgresql en MySQL dan zou het nog tot daar aan toe zijn...

tomato schreef op 15 June 2003 @ 18:49:
(kijk daarvoor eens in de sig van ACM).

Wist je dat ik zou reageren?

[Verwijderd]

ACM> ow langen uitleg, zal even deftige reply proberen te verzinnen:

basis: bekendheid & de vergelijkingen die toch nog een beetje recent waren op google.
DB2 & Sybase ken ik eigenlijk totaal niet, dus kwamen die ook niet voor in mijn google-search query... Ook niet echt veel over gelezen (db2 wel, sybase niet)

Eisen: UITERST (en ja hoofdletters) stabiel zijn. Ik reken op een klein 10G toch minstens als het eens goed begint te draaien.
Na in je link gekeken te hebben over je anti-mysql zal ik die zeker niet gaan gebruiken. Want ik kan me in dit opzicht geen fouten veroorloven.
Met uiterst stabiel bedoel ik niet alleen nooit (is dat mogelijk? ) crashen, fouten geven bij verkeerde inserts, fouten geven bij alles wat onlogisch is enzo...

simpele queries = inserten van data, en gecombineerde retrieval (desnoods aan de hand van keys). Indexes zullen ook geplaatst worden, maar daar weet ik nog niet zoveel van voor die efficient te gebruiken.
Deleten van data is niet echt nodig (behalve na x jaar voor uit archief te verwijderen). updaten normaal ook niet...

Meestal gaan de queries over 2 tot max 5 tabellen gaan, met elk toch een klein 100k records (voorlopig weeral).

[ Voor 8% gewijzigd door Verwijderd op 15-06-2003 19:12 ]

[ACM]

Verwijderd schreef op 15 juni 2003 @ 19:10:
basis: bekendheid & de vergelijkingen die toch nog een beetje recent waren op google.
DB2 & Sybase ken ik eigenlijk totaal niet, dus kwamen die ook niet voor in mijn google-search query... Ook niet echt veel over gelezen (db2 wel, sybase niet)

Helaas zijn de vergelijkingen nooit echt supergoede uitganspunten
Magoed, als het "wat mag kosten" zou ik in je plaatje ook zeker DB2 en Sybase opnemen.

Ik had bij DB2 echter wel het gevoel dat het erg star/beperkt was, hoewel het ook weer een aantal erg "kewle" features heeft (met vooral erg geinige wizards enzo )

Eisen: UITERST (en ja hoofdletters) stabiel zijn. Ik reken op een klein 10G toch minstens als het eens goed begint te draaien.
Na in je link gekeken te hebben over je anti-mysql zal ik die zeker niet gaan gebruiken. Want ik kan me in dit opzicht geen fouten veroorloven.

Mja, maar pas op dat ik geen autoriteit ben op dit gebied. Ik ken vooral postgresql en mysql en beide hebben nadelen (oracle, db2, sybase, etc ook ze zijn allen niet echt geschikt voor een forum heb ik het idee... terwijl mysql en postgres dat juist weer wel zijn) en voordelen.

Met uiterst stabiel bedoel ik niet alleen nooit (is dat mogelijk? ) crashen, fouten geven bij verkeerde inserts, fouten geven bij alles wat onlogisch is enzo...

Dan is mysql zeker een minder goede keuze (hoewel niet perse helemaal een afvaller).

Deleten van data is niet echt nodig (behalve na x jaar voor uit archief te verwijderen). updaten normaal ook niet...

Mooi, dat zijn twee punten waar Postgres relatief wat zwakker is. Aangezien het de gedelete en geupdate records niet compleet verwijdert, maar dit pas na een vacuum doet. Met veel updates (inserts maakt minder uit) kan je daardoor wel wat performance verlies ondervinden.
Overigens is dat allemaal te automatiseren en zijn ze druk bezig die nadelen weg te werken bij het postgres-dev-team. Net zo goed dat ze een aantal missende features aan het bijmaken zijn bij mysql.

Meestal gaan de queries over 2 tot max 5 tabellen gaan, met elk toch een klein 100k records (voorlopig weeral).

Iets wat ze alledrie wel aardig kunnen, maar het zal van de specifieke queries afhangen of MySQL nog goed mee kan komen door zijn zwakkere planner of juist dat mysql wint door zijn grotere eenvoud

[ Voor 5% gewijzigd door ACM op 15-06-2003 19:21 ]

[WimB]

Ik vraag me af waarom mySQL zoveel gebruikt wordt als Postgresql toch veel beter is. Postgresql is toch ook gratis?

[ACM]

WimB schreef op 15 juni 2003 @ 19:21:
Ik vraag me af waarom mySQL zoveel gebruikt wordt als Postgresql toch veel beter is. Postgresql is toch ook gratis?

Ik denk dat een paar belangrijke punten zijn:
Postgres is pas sinds versie 7.0/7.1 echt weer een serieuze speler geworden, imho. Versie 6.5 was wel aardig, maar miste nog wat dingen (vooral stabiliteit), 7.0 was nog steeds wel beperkt (8KB rowsizes bijv), 7.1 werd imho pas de eerste waar er serieus met andere spelers vergeleken kon worden.

MySQL is vanaf versie 3.23 relatief goed geweest, hoewel het natuurlijk de nodige instabiliteit kende en pas vrij laat de innodb-toevoeging kreeg...
MySQL is iets makkelijker te beheren en heeft "out of the box" een relatief goede performance, kortom het is allemaal wat makkelijker te gebruiken en bedienen.

En als dan het gros van de webhosters het opneemt krijg je een vergelijkbaar effect als windows op de desktop. "Veel hebben het", er wordt "veel voor ontwikkeld" en "meer gaan het dan gebruiken"

[Verwijderd]

Misschien omdat MySQL de default is in samenwerking met PHP.
Nouja dat is wat ik denk en voor simpele websites is MySQL wel degelijk interessant voor de snelheid met eenvoudige queries.

Als je eenmaal verder wil ga je toch wel het een en ander missen. Wat dat betreft verkies ik ook PostgreSQL maar daar mis je uiteindelijk ook nog het een en ander.

[chem]

Verwijderd schreef op 15 June 2003 @ 19:30:
Misschien omdat MySQL de default is in samenwerking met PHP.

Da's wel een heel bizarre opmerking

Alhoewel veel tutorials van mysql uitgaan, is er verder GEEN koppeling php+mysql. De reden dat veel tutorials mysql nemen; het is eenvoudig, en dus makkelijk uit te leggen.

[Brothar]

en met Delphi/Kylix als front-end ?
Blijft je keuze MySQL/PostgreSql dan hetzelfde ?

[Verwijderd]

Chem: PHP compileert toch echt default met MySQL support hoor. Ja ik weet heel goed dat je support voor andere DBMsen kan enablen maar neemt niet weg dat PHP default met MySQL support compiled. Wat volgens mij de reden is dat al die tutorials gelijk van MySQL uitgaan.
Ik zei niet dat PHP enkel met MySQL werkt ik zei dat het de default is.

ACM: Heb je misschien een link waar ik wat kan lezen over het tweaken van PostgreSQL voor betere performance?

[tomato]

ACM schreef op 15 June 2003 @ 19:24:
MySQL is iets makkelijker te beheren en heeft "out of the box" een relatief goede performance, kortom het is allemaal wat makkelijker te gebruiken en bedienen.

En is al lang gemakkelijk op Windows te installeren, wat voor veel beginnende ontwikkelaars zoals hier veel rond lopen ook een voordeel is.

[chem]

Verwijderd schreef op 15 June 2003 @ 19:43:
Chem: PHP compileert toch echt default met MySQL support hoor.

Dat is dus niet waar.

quote: http://www.php.net/mysql

Requirements

In order to have these functions available, you must compile PHP with MySQL support.

[J3roen]

chem schreef op 15 June 2003 @ 19:38:
[...]

Da's wel een heel bizarre opmerking

Alhoewel veel tutorials van mysql uitgaan, is er verder GEEN koppeling php+mysql. De reden dat veel tutorials mysql nemen; het is eenvoudig, en dus makkelijk uit te leggen.

Ik weet niet precies wat je met de koppeling bedoelt, maar mySQL wordt *altijd* meegecompileerd. Ook als je geen mySQL geinstalleerd hebt. Zei het dat deze functionaliteit dan beperkter is dan wanneer je MySQL wel geinstalleerd hebt en er bewust voor kiest om mee te compileren.

[ACM]

Verwijderd schreef op 15 juni 2003 @ 19:43:
ACM: Heb je misschien een link waar ik wat kan lezen over het tweaken van PostgreSQL voor betere performance?

Humm, dat is er helaas niet heel veel. Maar aardige plaatsen zijn deze:
http://www.postgresql.org...ook/hw_performance/0.html
http://www.postgresql.org/docs/aw_pgsql_book/node106.html (is dezelfde als deze)

Maar ik zag zo gauw geen documentatie over de Free Space Map (FSM) en optimale groottes voor de caches enzo, waar in de mailinglists nog wel het een en ander over vermeld wordt.


Btw, kap es met dat welles-nietes over mysql. Het wordt ondertussen veel gebruikt. (punt dus)
En een aantal redenen zijn hier genoemd.

[ Voor 10% gewijzigd door ACM op 15-06-2003 19:58 ]

[Apache]

chem schreef op 15 juni 2003 @ 19:49:
[...]
Dat is dus niet waar.


[...]

As of PHP 4, --with-mysql is enabled by default so to disable MySQL support you must use --without-mysql.

vanaf dezelfde pagina trouwens.

Het is dus maar hoe je het bekijkt

[curry684]

Uhm ja na 20 posts heeft het nog steeds niets inhoudelijk met P&W van doen maar is het wel een goede gezellige discussie over Linux-software... Moved to NOS dus.

En een MSN-discussietje met ACM verder hebben we 'm weer terug richting /14 gekicked

[ Voor 36% gewijzigd door curry684 op 15-06-2003 20:43 ]

[Verwijderd]

je gaat kiezen uit het rijtje mysql, postgre en oracle voor een bedrijfskritische db met 1o gig aan data en 10000en transacties/dag zou ik voor oracle kiezen, vanwege het feit dat deze zich toch beter bewezen heeft binnen grote organisaties. vooral het bedrijfskritische punt is dan belangrijk vind ik, voor dit soort acties heb ik meer vertrouwen bij een closed dan een opensource db.

ook heeft oracle een betere / snellere indexmethode, alhoewel de opensource varianten met 100k records ook nog wel kunnen meekomen, maar toch midner presteren dan oracle.

een heel groot tegenargument is de prijs. daar sla je stijl van achter over. maar als het echt een bedrijfskritische app is, die echt niet kapot mag moet de prijs van minder belang zijn aangezien downtime dan vele tonnen of miljoenen kan gaan kosten, e.e.a. hangt af van de omvang van de organisatie

[ACM]

En we vonden het toch meer passen in P&W, excuus voor het ongemakt

[jochemd]

Verwijderd schreef op 15 June 2003 @ 20:30:

ook heeft oracle een betere / snellere indexmethode, alhoewel de opensource varianten met 100k records ook nog wel kunnen meekomen, maar toch midner presteren dan oracle.

Hoe bedoel je, beter? Oracle gebruikt toch ook gewoon standaard RTREE's en BTREE's?

[GBits]

Wat een op een tenen getrapte reakties zeg.
Tuurlijk weet ik dat mijn reaktie een flaimbate voor veel mod's is.
Punt alleen dat ik wilde maken is dat als je een 'beste' database wil hebben je veel meer zaken op een rijtje moet hebben dan de topicstarter had/heeft.

Dat je bijv DB2 sluit je ook uit als je Linux als uitgangspunt neemt, dat had degene die het opperde ook wel kunnen bedenken.
Maar het is dus eigenlijk van belang om aan te geven dat je OS keuze in principe niet leidend moet zijn. Dat was eigenlijk het punt wat ik wilde maken, heb nu spijt dat ik het in eerste instantie niet wat uitgebreider deed.

Verder nog even een oproep aan de mod's en wannabee mod: check even tegen wie je zo respectloos zit te reageren, ik loop hier al 4 jaar rond en hoop in 99% een zinnige bijdrage te leveren.

[ACM]

Lecram schreef op 15 June 2003 @ 21:03:
Punt alleen dat ik wilde maken is dat als je een 'beste' database wil hebben je veel meer zaken op een rijtje moet hebben dan de topicstarter had/heeft.

Helemaal mee eens, maar daarentegen was er een duidelijke eis kwa OS en dat was linux.

Dat je bijv DB2 sluit je ook uit als je Linux als uitgangspunt neemt, dat had degene die het opperde ook wel kunnen bedenken.

Grappig, twee maanden geleden had ik nog een testsetupje met DB2 8.1 op mijn linux server
't Is zelfs al meer dan een jaar ervoor beschikbaar meen ik (versie 7.2 uiteraard)

Maar het is dus eigenlijk van belang om aan te geven dat je OS keuze in principe niet leidend moet zijn. Dat was eigenlijk het punt wat ik wilde maken, heb nu spijt dat ik het in eerste instantie niet wat uitgebreider deed.

Zulk soort reacties onderbouwen is idd verstandig, men vat ze gegarandeerd verkeerd/anders op.

Verder nog even een oproep aan de mod's en wannabee mod: check even tegen wie je zo respectloos zit te reageren, ik loop hier al 4 jaar rond en hoop in 99% een zinnige bijdrage te leveren.

Jouw reactie kwam ook niet respectvol over
Maar laten we er over ophouden, misverstanden zijn er om op te lossen en niet om mee door te gaan

[JaQ]

Zelf heb ik ondertussen ruim ervaring met Oracle, redelijk tot veel ervaring met postgresql, mysql en sapdb en wat kleine ervaringen met sleepycat, ldap en firebird. Ik kan je een ding wel vertellen: er bestaat geen beste database. Je kan hard roepen: Oracle is de beste (maar dat geld niet voor een kleine webapplicatie waarin alleen maar geselecteerd wordt) etc. etc.

Je moet je dus ten eerste goed afvragen wat je wilt met je database. Daar ben je geloof ik al redelijk uit ondertussen. (wel knap trouwens dat je zonder het databasetype bepaald te hebben de omvang in GB/MB's kan bepalen ) Ik mis alleen nog of je eventueel een procedural language wilt gaan gebruiken, of dat je kiest voor logica in je applicatie. Persoonlijk kies ik bijna in alle gevallen voor een procedural language, maar ik ben dan ook meer een database persoon dan een scripttaal persoon.

Ten tweede moet je goed nadenken over beheer/administratie van je database. De ene database is nou eenmaal wat gemakkelijker te beheren / administreren dan de andere. Denk dan niet alleen aan backups, maar ook aan tuning. De kosten van administratie moet je overigens niet onderschatten (en ook meenemen in je database keuze).

De laatste weken ben ik bezig met het testen van SapDB en ik ben tot op heden redelijk onder de indruk. Zeer stabiel en gemakkelijk te beheren. Groot nadeel is wel dat er weinig goede documentatie aanwezig is (mailinglists doen wel wonderen gelukkig). Het leertraject is dus wat langer dan bij een goed gedocumenteerde database. Voor mijn huidige project heb ik echter sapdb links laten liggen en voor postgresql gekozen. (ondanks dat ik daar ook nadelen in vind, vooral op het administratie vlak).

Kortom: ik denk dat je de juiste criteria nog niet op een rijtje hebt. Daarna is het volgens mij gewoon een matrix maken met voor en nadelen van de verschillende databases en net zolang gaan strepen totdat er 1 overblijft.

[Femme]

MySQL (over andere databases kan ik niet oordelen) moet prima geschikt zijn voor de toepassing die jij voor ogen hebt. De laatste versies zijn uitermate stabiel. Om maar weer even Tweakers.net als voorbeeld te geven: MySQL 3.23.54 heeft hier nu een uptime van bijna 179 dagen en dat bij gemiddeld zo'n 350 queries per seconde met pieken tot 2600 queries per seconde. Tabellen met tientallen miljoenen records of veel inserts (meer dan 800K per dag) zijn geen probleem. Met de juiste optimalisaties (qua queries, indices, geheugeninstellingen, tabeltypen, hardware e.d.) is de schaalbaarheid erg goed.

Vroegere versies van MySQL hebben wel eens rare problemen gehad zoals spontane crashes tijdens het uitvoeren van zware queries. Sinds 3.23.49 loopt MySQL heb ik eigenlijk geen stabiliteitsproblemen meer gehad, ook niet met hele zware queries van meer dan vijf minuten.

MySQL is alleen snel met echt simpele queries, de queryanalyzer/planner van MySQL is zeer slecht vergeleken met die van Oracle en PostgreSQL maar door de eenvoud wint mysql het bij vrijwel alle echt simpele queries kwa performance.

'Zeer slecht' is misschien wat overdreven. In sommige gevallen (complexe queries met veel joins) pakt de analyzer een verkeerde benadering waardoor queries erg traag zijn en je met de hand moet optimaliseren. Of dat nou zo'n groot probleem is betwijfel ik. Als developer zou je al je complexe queries toch moeten checken op snelheid. Als je eenmaal een beetje weet waar MySQL gevoelig voor is, is het geen moeite meer om queries te optimaliseren.

je gaat kiezen uit het rijtje mysql, postgre en oracle voor een bedrijfskritische db met 1o gig aan data en 10000en transacties/dag zou ik voor oracle kiezen, vanwege het feit dat deze zich toch beter bewezen heeft binnen grote organisaties. vooral het bedrijfskritische punt is dan belangrijk vind ik, voor dit soort acties heb ik meer vertrouwen bij een closed dan een opensource db.

Voor simpele update/select/insert/delete queries is MySQL hoogstwaarschijnlijk sneller vanwege het simpele feit dat MySQL minder baggage aan boord heeft. Voor support kun je aankloppen bij MySQL AB, dus ook dat is niet zo'n probleem.

[curry684]

Femme schreef op 15 June 2003 @ 22:51:
MySQL 3.23.54 heeft hier nu een uptime van bijna 179 dagen en dat bij gemiddeld zo'n 350 queries per dag met pieken tot 2600 queries per seconde.

Je bent nu reclame aan het maken voor noch t.net noch MySql hoor

[Verwijderd]

Verwijderd schreef op 15 June 2003 @ 19:10:
Eisen: UITERST (en ja hoofdletters) stabiel zijn.

...

Want ik kan me in dit opzicht geen fouten veroorloven.

You know what they say: "Nobody ever got fired for buying Oracle".

Ik ben zelf absoluut geen Oracle fan overigens, maar ik snap goed dat grote bedrijven geen risco's willen nemen met hun database en daarom kiezen voor de marktleider (hoewel IBM recent heeft beweerd de #1 overgenomen te hebben, maar daarover zijn beide bedrijven het niet bepaald eens) die op het gebied van betrouwbaarheid een naam hoog te houden heeft.

Neem het volgende (waargebeurde) scenario: de grootste bank van Denemarken heeft heel recent 4 dagen lang niet correct heeft kunnen functioneren vanwege een viertal bugs in IBM's DB2 database.

Zo'n grote bank kan zich op dat gebied dus ECHT geen fouten veroorloven. Stel nu dat jij daar, na een avondje Tweakers lezen, verantwoordelijk was geweest voor de keuze van PostgreSQL of MySQL ipv DB2 en jij moet bij je baas op het matje komen om uit te leggen hoe dat heeft kunnen gebeuren. Naast hem zit dan waarschijnlijk een jurist die hem zojuist heeft uitgelegd dat hij zijn rechtzaak wel kan vergeten, enerzijds omdat er niets betaald is voor de software en anderzijds omdat, zelfs als ze al een zaak hadden, het bedrijf achter de database gewoon geen geld heeft en een rechtzaak of schikking dus nutteloos zou zijn.

Misschien volgt er dan een (technische) discussie over de voors en tegens van OSS en Postgre- of MySQL, maar ik kan je nu al vertellen wat jou (a-technische) baas op een gegeven moment als argument naar voren zal brengen:

"You get what you payed for"

Dit is overigens geen FUD richting OSS hoor, het is werkelijk waar een belangrijke reden waarom Oracle vaak gekozen wordt boven andere databases: Het is gewoon de veiligste keuze.

Als jij stelt dat je je echt geen fouten kan veroorloven op dit gebied zou ik gaan voor de Oracle. En als stabiliteit echt zo belangrijk is snap ik de keuze voor Linux overigens ook niet zo goed....

modbreak: degene die een flamewar start binnen dit topic kan problemen tegemoet zien. De laatste zin van Paul zou ik ook graag beter onderbouwd zien maar is zeker een goede insteek voor een normale discussie.

[ Voor 7% gewijzigd door curry684 op 16-06-2003 00:15 ]

[justmental]

jochemd schreef op 15 juni 2003 @ 20:49:
[...]
Hoe bedoel je, beter? Oracle gebruikt toch ook gewoon standaard RTREE's en BTREE's?

En bitmap indexen, function based indexen, omgekeerd gesorteerde indexen, indexen met histogrammen.

[ACM]

Verwijderd schreef op 15 juni 2003 @ 23:40:
Neem het volgende (waargebeurde) scenario: de grootste bank van Denemarken heeft heel recent 4 dagen lang niet correct heeft kunnen functioneren vanwege een viertal bugs in IBM's DB2 database.

Zo'n grote bank kan zich op dat gebied dus ECHT geen fouten veroorloven. Stel nu dat jij daar, na een avondje Tweakers lezen, verantwoordelijk was geweest voor de keuze van PostgreSQL of MySQL ipv DB2 en jij moet bij je baas op het matje komen om uit te leggen hoe dat heeft kunnen gebeuren. Naast hem zit dan waarschijnlijk een jurist die hem zojuist heeft uitgelegd dat hij zijn rechtzaak wel kan vergeten, enerzijds omdat er niets betaald is voor de software en anderzijds omdat, zelfs als ze al een zaak hadden, het bedrijf achter de database gewoon geen geld heeft en een rechtzaak of schikking dus nutteloos zou zijn.

Jij wilt beweren dat er wel een rechtzaak tegen IBM mogelijk is hieromtrent? 't Zal vast van het supportcontract afhangen, maar ik zie eerlijk gezegd niet in waarom een bank _meer_ zou mogen eisen voor de rechter dan elke andere gebruiker en volgens mij hebben de meeste gebruikers van software weinig poten om op te staan...

Overigens kan je zowel Postgresql als Mysql gewoon kopen, voor postgres ken ik een aantal bedrijven (oa redhat) die een commerciele versie met (uitgebreide) support verkopen en hoewel die bedrijfjes kleiner zijn zie ik niet in waarom zij per definitie minder zouden moeten zijn.

Misschien volgt er dan een (technische) discussie over de voors en tegens van OSS en Postgre- of MySQL, maar ik kan je nu al vertellen wat jou (a-technische) baas op een gegeven moment als argument naar voren zal brengen:

"You get what you payed for"

Das dan jammer voor die baas, want het viel allemaal onder zijn verantwoordelijkheid en hij had dat dus goed moeten laten lopen. Als hij geen "gratis database" had gewild had ie dat maar aan moeten geven...

Als jij stelt dat je je echt geen fouten kan veroorloven op dit gebied zou ik gaan voor de Oracle. En als stabiliteit echt zo belangrijk is snap ik de keuze voor Linux overigens ook niet zo goed....

Onderbouw dat eens? Oracle levert support voor linux, IBM levert support voor linux, Intel en HP leveren er support voor... Een aantal zeer grote bedrijven die iig aan de buitenwereld hebben laten weten geinteresseerd te zijn in de ontwikkelingen om en rond Linux. Ik zie niet in waarom Linux niet stabiel zou kunnen zijn, sterker nog... Ik zie regelmatig linuxservers die zeer stabiel zijn.

Maarja, you get what you paid for... Als het extreem stabiel moet, zou je idd es een IBM Z-series doos moeten bekijken oid, die kunnen bij wijze van spreken niet stuk, en daar dan DB2 met een of ander zeer duidelijk supportcontract op draaien. Daar betaal je dan ook al gauw een miljoen dollar voor kwa hardware en een vergelijkbaar bedrag voor de DB2 (en tools) licenties, maar goed...

Ik heb lichtelijk het idee dat het hier over een iets andere toepassingsgebied gaat dan een bank of iets dergelijks...

Hoewel het zeker waar is dat DB2, Oracle, e.a. vast stabieler zijn op een of andere proprietary Unix op een stuk hardware van tienduizenden euro's is er natuurlijk wel een zekere grens die je absoluut niet hoeft te overschrijden voor jouw eigen applicatie. Voor een bank ligt die grens erg hoog, voor een simpele "bedrijfskritische" applicatie hoeft dat toch echt niet lijkt mij...

[jochemd]

justmental schreef op 15 June 2003 @ 23:55:

En bitmap indexen, function based indexen, omgekeerd gesorteerde indexen, indexen met histogrammen.

En wat maakt die beter dan expression based indexen, omgekeerd gescande indexen, GIST indexen en partiele indexen in PostgreSQL?

Ik kan me voorstellen dat voor bepaalde queries, bijvoorbeeld waarbij er grote aggregrate uitgerekend moeten worden, gematerialiseerde indexen (waarbij het volledige tuple op de leaf-nodes wordt opgeslagen) een gemis zijn in PostgreSQL. Maar of je die nodig hebt hangt maar net van je toepassing af.

[Verwijderd]

DrFrankstoner> Een GB is erg groot, die rij (met eventuele datatypes die toch niet zo echt veel gaan verschillen in elke db-opslag) is vrij klein (een kleine 58bytes groot \ lijn), dus ik schatte dat op een 10G (die HDD van die server is groot genoeg voor dit geval ). --- Verder kies ik liever voor scripten dan voor coden in de database (als je bedoelt met transactions enzo maken). --- En als reply op je adminnen kan ik zeggen: Ik ga het 1x opzetten, tweaken, ... maar erna moet dat gewoon blijven draaien, zo simpel is dat.

ACM> Hier is het niet een bank, maar het gaat wel een bom geld & ik vrees dat mijn baas niet akkoord gaat zijn als ik met een voorstel kom voor een zeer dure db aan te schaffen [ daarmee ook dat ik het idee van Oracle beetje uit de weg ga, alhoewel ik weet dat die vree betrouwbaar is enzo ]

Verder heb ik linux gekozen wegens de gemakkelijkheid om shellscripts te maken, crons te laten lopen etc etc

[ Voor 9% gewijzigd door Verwijderd op 16-06-2003 14:54 ]

[Eijkb]

Het gaat over miljoenen maar het mag niets kosten? Nederlands bedrijf? Ach, ik ken het wel hoor. Doe ook veel opdrachten die voor weinig kosten net zoiets moois en betrouwbaars moeten opleveren als de buren het hebben voor duizenden euro´s...

[kenneth]

Verwijderd schreef op 16 June 2003 @ 14:53:
Verder heb ik linux gekozen wegens de gemakkelijkheid om shellscripts te maken, crons te laten lopen etc etc

Zit je er al aan vast? Anders zou ik ook naar de BSD's kijken, die hebben zeker wat te bieden.

[Creepy]

Lecram schreef op 15 June 2003 @ 21:03:
Wat een op een tenen getrapte reakties zeg.
Tuurlijk weet ik dat mijn reaktie een flaimbate voor veel mod's is.
Punt alleen dat ik wilde maken is dat als je een 'beste' database wil hebben je veel meer zaken op een rijtje moet hebben dan de topicstarter had/heeft.

Dat je bijv DB2 sluit je ook uit als je Linux als uitgangspunt neemt, dat had degene die het opperde ook wel kunnen bedenken.

eehh..Bedoel je hier dat je DB2 uitsluit als je Linux draait? *kuch*
http://www-3.ibm.com/software/data/db2/linux/validate/

[ Voor 34% gewijzigd door Creepy op 16-06-2003 15:26 ]

[Verwijderd]

Ik zit voorlopig nog aan niets vast, daarmee dat ik wat zit te hengelen wat voor een toch vrij belangrijke applicatie is. Ik zoek eigenlijk iets wat kwa prijs/kwaliteit goed werk levert. Dus bvb als MySQL/PostgreSQL ietsje slechter is dan Oracle/..., dan opteer ik voor die 2 eerste, daar de prijs van Oracle nogal hoog kan zijn. Maar als ik (en mijn baas met mij) nu zie dat Oracle enorme voordelen inzake stabiliteit en snelheid heeft tov andere varianten, dan zal de voorkeur daar toch wel heen gaan.

En eijkb, het maakt niet uit of dit nu NL bedrijf is ja dan nee. Dit is een discussie over voor- & nadelen van bestaande databases, niet over de leiding & bedrijfsvoering.

[JaQ]

1 keer opzetten en niets meer aan doen gaat je niet zomaar lukken. (je zal dan het complete admin proces moeten automagiseren). Je loop tegen erg nare grappen aan (zoals dat je bijvoorbeeld geen passwords aan de postgresql backup-software kan voeren in een script, moet userinput zijn, etc). Is denk ik een redelijke utopie.

Busniness rules in je scripting (b.v. php) is uiteraard goed mogelijk. Als je voor mysql kiest zal je ook wel moeten (foreign keys in MySql is een bijzonder verhaal, je kan ze wel aanmaken, maar ze worden niet gecontroleerd*.. erg bijzonder) Persoonlijk vind ik foreign-keys, unique keys en check constraints altijd wel erg handig (en veel gemakkelijker in een db dan in een script vast te leggen, ik moet er niet aan denken om in b.v. php elke foreign key "handmatig" te moeten controleren...)

* Althans in de laatste versie die ik heb bekeken.

edit:
toevoeging: postgresql of mysql is niet per definitie minder goed dan Oracle, hangt van je doel af utieraard.

[ Voor 9% gewijzigd door JaQ op 16-06-2003 16:24 ]

[jochemd]

DrFrankenstoner schreef op 16 June 2003 @ 16:22:
1 keer opzetten en niets meer aan doen gaat je niet zomaar lukken. (je zal dan het complete admin proces moeten automagiseren). Je loop tegen erg nare grappen aan (zoals dat je bijvoorbeeld geen passwords aan de postgresql backup-software kan voeren in een script, moet userinput zijn, etc).

Uitgaande van de standaard pg_dump en psql: als je eerder in je scriptje even je password als environment variabele zet wordt er niet om gevraagd.

[ACM]

jochemd schreef op 16 juni 2003 @ 18:57:
Uitgaande van de standaard pg_dump en psql: als je eerder in je scriptje even je password als environment variabele zet wordt er niet om gevraagd.

Of je kan natuurlijk een speciaal "backup account" maken, dat wel leestoegang tot de benodigde db's heeft en via de lokale shell gewoon toegang op ident krijgt (dus indien "ingelogd als backupmanager dan ook toegang") oid.

Er zijn wat beter en wat minder beveiligde methodes om die toegang toch redelijk goed te kunnen regelen.

[jochemd]

ACM schreef op 16 June 2003 @ 19:38:

Er zijn wat beter en wat minder beveiligde methodes om die toegang toch redelijk goed te kunnen regelen.

Kerberos

[JaQ]

jochemd schreef op 16 June 2003 @ 18:57:
[...]
Uitgaande van de standaard pg_dump en psql: als je eerder in je scriptje even je password als environment variabele zet wordt er niet om gevraagd.

is dat een gedocumenteerde feature? Zo ja, zou je daar een voorbeeld van kunnen geven? (klinkt interessant namelijk)

[Yo-han]

Zoek ook eens naar het bestandje CrashMe. Dit vergelijkt veel verschillende db's.

Gevonden: Crashme test mysql

[ Voor 68% gewijzigd door Yo-han op 17-06-2003 00:43 ]

[jochemd]

DrFrankenstoner schreef op 17 June 2003 @ 00:28:

is dat een gedocumenteerde feature? Zo ja, zou je daar een voorbeeld van kunnen geven? (klinkt interessant namelijk)

Volgens mij was het:
set PGPASSWORD=supergeheim

http://archives.postgresql.org is je vriend

[jochemd]

dayoman schreef op 17 juni 2003 @ 00:38:
Zoek ook eens naar het bestandje CrashMe. Dit vergelijkt veel verschillende db's.

CrashMe heeft helaas zelf ook zijn beperkingen
Maar nog afgezien daarvan, het is toch veel simpeler om even met je eigen applicatie een simpel testscenario te maken? Dan weet je tenminste zeker dat je dingen test die je zelf nodig hebt.

[Yo-han]

jochemd schreef op 17 June 2003 @ 00:44:
[...]
CrashMe heeft helaas zelf ook zijn beperkingen
Maar nog afgezien daarvan, het is toch veel simpeler om even met je eigen applicatie een simpel testscenario te maken? Dan weet je tenminste zeker dat je dingen test die je zelf nodig hebt.

true, maar blijft relaxed om het ook even naast elkaar te zien. Als je daarvoor getest hebt moet het niet lang duren voordat je je keuze hebt kunnen maken

[WimB]

Hoe zit het eigenlijk met de stabiliteit en snelheid van mySQL 4.x t.o.v. mySQL 3.x

Want het is niet enkel de database die belangrijk is. De versie bepaalt volgens mij ook heel wat.

[Yo-han]

MySQL verklaard dat hun database op windows zoiezo 50% langzamer draait dan op Linux. Verder zijn er zover ik weet geen al te grote aanpassingen gedaan op de snelheid. (is al snel ). Maar een beetje geheugen en goeie hardeschijf doen wonderen.

[xoror]

Ik heb zelf redelijke ervaring met mysql en pgsql.
Waar het eigenlijk op neerkomt is dat je de juiste tool moet kiezen voor je taak.
Het beste is om de gene die je wil inzetten ook echt te testen. (dus met de verwachte load voeren en kijken hoe hij performt)

Wat ik wel weet is dat mysql wel eens dood gaat (zelf aantal keren meegemaakt). voor bepaalde apps is dat niet z'n probleem. Ik heb nog geen crashes mee gemaakt van pgsql. Maar als pgsql crashed (kan je simuleren door power bijv uit te gooien als ie druk bezig is), recoverd hij door WAL wel naar consistente staat. Bij mysql kan je worden opgescheept met corrupte db's. (innoDB zou dit ook moeten oplossen, alleen is mysql + innodb een stuk trager dan mysql met myisam)

Een groot voordeel van pgsql is dat je veel logic in stored procs en triggers kan stoppen. (dit voordeel heeft elke db met triggers en stored procs/udf's)
Het grootste nadeel van pgsql is dat hij geen goede ingebouwde garbage collector heeft waardoor je zelf je space moet reclaimen. Hetzelfde geldt voor de indices. (ik kan er wel mee leven, elke nacht vacuum full draaien en 1x in de maand reindexen oid).

ik wilde zelf nog firebird (http://firebird.sf.net) proberen. Qua features is deze ongeveer gelijk aan pgsql. Echter zit hier ingebouwde garbage collector in (die je ook kan uit zetten, maar dan moet je handmatig garbage collecten (dan heb je zelfde situatie als met pgsql)).

[xoror]

dayoman schreef op 18 June 2003 @ 00:29:
MySQL verklaard dat hun database op windows zoiezo 50% langzamer draait dan op Linux. Verder zijn er zover ik weet geen al te grote aanpassingen gedaan op de snelheid. (is al snel ). Maar een beetje geheugen en goeie hardeschijf doen wonderen.

mysql is trager op windows omdat het via cygwin emulatie draait.

[Femme]

WimB schreef op 17 juni 2003 @ 08:07:
Hoe zit het eigenlijk met de stabiliteit en snelheid van mySQL 4.x t.o.v. mySQL 3.x

Want het is niet enkel de database die belangrijk is. De versie bepaalt volgens mij ook heel wat.

De database van Fok! draait sinds een paar maanden op MySQL 4.0 en die is voor zover ik heb begrepen nog niet gecrashed. Die doos heeft een behoorlijke load en draait op een beetje ondermaatse hardware, dus je kunt wel zeggen dat MySQL 4.0 behoorlijk stabiel is. MySQL 3.23.54 is rock solid, nu op 182 dagen uptime @ Artemis .

(innoDB zou dit ook moeten oplossen, alleen is mysql + innodb een stuk trager dan mysql met myisam)

MySIAM is voor simpele queries vaak net iets sneller, maar het verschil met InnoDB is doorgaans niet dramatisch.

[xoror]

Femme schreef op 19 June 2003 @ 01:13:
[...]


De database van Fok! draait sinds een paar maanden op MySQL 4.0 en die is voor zover ik heb begrepen nog niet gecrashed. Die doos heeft een behoorlijke load en draait op een beetje ondermaatse hardware, dus je kunt wel zeggen dat MySQL 4.0 behoorlijk stabiel is. MySQL 3.23.54 is rock solid, nu op 182 dagen uptime @ Artemis .


[...]


MySIAM is voor simpele queries vaak net iets sneller, maar het verschil met InnoDB is doorgaans niet dramatisch.

Het zit hem niet in de simpelheid van de queries. Het zit hem onder andere in de hoveelheid data die bijv een query aanpast. stel je hebt een query die 10k records aanpast, met myisam wordt dat dus gewoon doorvoeren. InnoDB moet meer doen. Het moet maatregelen nemen om de query ook te kunnen terugdraaien. Ook soort write ahead logging (of vergelijkbaar mechanisme) gebruiken om te recoveren (in het geval van een stroomstoring). Wat dacht je daarnaast nog van checkpoints en gegevens die hij nodig heeft voor bijv point in time recovery. etc etc

er komt dus relatief veel overhead bij kijken. De performance drop zul je goed merken. (bedenk ook dat in multi version systemen aggregatie funkties als count() etc ook stukken trager zijn.)

Het is de prijs die je graag wil betalen om je data safe te houden. Je moet je wel realiseren dat het ten koste van performance gaat. Maar wat heb je aan performance als je data corrupt raakt...

[Verwijderd]

Verwijderd schreef op 15 June 2003 @ 18:38:
Welk is de beste database? Ik heb al een pak gelezen online, maar nog niet echt een deftige vergelijking gevonden, misschien dat gulle meerdere db kennen zodat ik kan vergelijken?

Ze moet draaien op linux, UITERST stabiel zijn, gewoon simpele update/select/insert/delete toestaan. Enorm grote data bewaren + zeer goede indexering hebben voor snelle retreival.

Welke ik na mijn selecties heb overgehouden zijn: Oracle, MySQL & PostgreSQL.


Zijn er die ik nog moet bekijken? Kent er iemand meerdere daarvan & kan die persoon op basis van zijn ervaring mij zeggen welk de betere is van de 2?

Als je bereid bent om (flink) te betalen, dan Oracle. Ga anders (voor de robuustheid) voor PostgreSQL of (voor de snelheid) voor MySQL (hoewel MySQL en PostgreSQL qua features en kwaliteiten steeds meer naar elkaar toe groeien).

Daarnaast is er ook nog (zoals door anderen hier genoemd) Firebird. Dat is een verder ontwikkelde versie van een release van Interbase (ik meen versie 6.0) waarvan de sourcecode destijds door Borland onder de Mozilla Public License (MPL) was vrijgegeven.

Over de andere commerciele databases kan ik helaas niets zeggen. Wat IBM heeft (ik meende Informix), is dat misschien wat?

[xoror]

Over de andere commerciele databases kan ik helaas niets zeggen. Wat IBM heeft (ik meende Informix), is dat misschien wat?

IBM heeft DB2, ze hebben informix erbij gekregen nadat ze die overgenomen hadden. Informix is wel goede db server. heb er ook tijdje meegewerkt.

[xoror]

ik heb net gelezen dat het index-groei-probleem-zonder-reindex is opgelost met 7.4 die over 2 weken in beta gaat. dit is goed nieuws. er zit ook een soort auto_vacuum deamon bij die de db automatisch vacuumed. Het moeten reindexen om de zoveel tijd vond ik een groot nadeel. ben blij dat dat straks opgelost is.

wat jammer is is dat (zeker weten) geen replicatie in 7.4 zit en __waarschijnlijk__ is de win32 port en pitr ook niet op tijd klaar. ik geloof dat ze wellicht vlak na 7.4 evt een win32port + pitr willen releasen. maar jah dit was het zelfde strijdplan voor 7.3

[Verwijderd]

Femme schreef op 19 June 2003 @ 01:13:De database van Fok! draait sinds een paar maanden op MySQL 4.0 en die is voor zover ik heb begrepen nog niet gecrashed. Die doos heeft een behoorlijke load en draait op een beetje ondermaatse hardware, dus je kunt wel zeggen dat MySQL 4.0 behoorlijk stabiel is.

Om Femme zijn post te staven, wij draaien op Sugababes ook al een paar maanden op MySQL 4 en tot nu toe is het rockstabiel. (we doen gemiddeld 110 queries/sec, ook op ondermaatse hardware).

De keus blijft altijd lastig. Zelf zou ik op het ogenblik voor Postgres kiezen omdat er:
a geen geld is voor Oracle
b ik dingen als subselects en dergelijke features van een echt dbms mis in Mysql
c de punten die ACM noemt in zijn signature over MySQL af en toe erg hinderlijk zijn

[Verwijderd]

xoror schreef op 20 juni 2003 @ 10:18:
ik heb net gelezen dat het index-groei-probleem-zonder-reindex is opgelost met 7.4 die over 2 weken in beta gaat. dit is goed nieuws. er zit ook een soort auto_vacuum deamon bij die de db automatisch vacuumed. Het moeten reindexen om de zoveel tijd vond ik een groot nadeel. ben blij dat dat straks opgelost is.

wat jammer is is dat (zeker weten) geen replicatie in 7.4 zit en __waarschijnlijk__ is de win32 port en pitr ook niet op tijd klaar. ik geloof dat ze wellicht vlak na 7.4 evt een win32port + pitr willen releasen. maar jah dit was het zelfde strijdplan voor 7.3

Vooral het wachten op de replicatie duurt inmiddels lang... Hopelijk gaan ze dat nu echt goed (en betrouwbaar) regelen, dan wordt het een zeer interessante optie...

[Onno]

Femme schreef op 19 June 2003 @ 01:13:
De database van Fok! draait sinds een paar maanden op MySQL 4.0 en die is voor zover ik heb begrepen nog niet gecrashed. Die doos heeft een behoorlijke load en draait op een beetje ondermaatse hardware, dus je kunt wel zeggen dat MySQL 4.0 behoorlijk stabiel is.

En hoeveel van de features in MySQL 4.0 gebruikt Fok? Zolang je niet alles gebruikt lijkt het me vrij twijfelachtig om een uitspraak te doen over de algehele stabiliteit van een programma.

_{(en of hardware nou langzaam of supersnel is hoort al helemaal geen invloed te hebben op de stabiliteit)}

[ACM]

Onno schreef op 20 June 2003 @ 21:44:
En hoeveel van de features in MySQL 4.0 gebruikt Fok? Zolang je niet alles gebruikt lijkt het me vrij twijfelachtig om een uitspraak te doen over de algehele stabiliteit van een programma.

Ik meen dat ze iig wel gebruik van de query-cache maken, maar sowieso van alles wat ze ook in 3.23.x deden, dus in die zin is het wel een goede vergelijking met de 3.23.x serie.

_{(en of hardware nou langzaam of supersnel is hoort al helemaal geen invloed te hebben op de stabiliteit)}

Klopt, denk dat dat ook meer een performance indicatie was, hoewel een zwaarder belaste server nog wel eens sneller schijnt te kunnen crashen dan een lichte (niet dat dan de hardware heel stabiel is )