MySQL vs pgSQL

[jbdeiman]

Hoi allemaal,

Ik heb een vraag voor diegenen die ervaring hebben met grotere applicaties in Mysql of PostgreSql (pgsql), liefst met beiden. Ik zal hieronder even uitleggen hoe de situatie is:

Momenteel hebben we een applicatie met daarin tabellen met meerdere miljoenen records, op zich geen probleem, maar we gaan de applicatie helemaal herschrijven (lees: opnieuw beginnen, met een schone lei, maar wel met de kennis van nu) en zijn daarbij aan het onderzoeken wat voor database systeem erachter moet gaan hangen. Een paar vallen al af (betaald, omdat het hele idee van het pakket is dat het zonder bijkomende kosten moet kunnen draaien | SQlite, ivm het snel zijn bij kleine query's, maar traag wanneer het wat ingewikkelder wordt) en we zijn blijven hangen op:
- PostgreSql
- Mysql.

Momenteel werkt het systeem op MySql, maar migratie naar PostgreSql moet prima te doen zijn. Daarbij zijn er voor en nadelen voor beide systemen, maar uiteindelijk komen we redelijk op gelijke hoogte uit qua beide databases:
- Data integriteit: Standaard in Postgre, maar ook af te dwingen in MySQL
- Select query's sneller (vaak) in Postgre, maar Inserts die we ook veel gebruiken, zijn weer sneller in MySQL
- Met InnoDB in MySQL (ivm relaties) wordt db alleen maar groter, is in PgSQL (ook met relaties) weer niet zo.

Zoals jullie lezen komen de voor ons belangrijke punten (snelheid/ betrouwbaarheid) aan beide kanten echt wel terug, mits goed geconfigureerd. De relaties zijn in elk geval erg belangrijk, en er zijn er behoorlijk veel van.

Goed, de vraag is ook, welk van beide databases zouden jullie kiezen/ gebruiken, en dan vooral waarom?
Wat is hét voordeel waardoor we voor 1 van beide systemen zouden gaan kiezen?

Alvast bedankt voor het meedenken hierin.

[MueR]

Even een tik naar Software Engineering & Architecture

[Wierdo_NL]

Ik zou voor Postgres gaan.

De inserts mogen inderdaad langzamer zijn.
Maar de data integriteit is echt goed, het is een erg volwassen product.
Meerdere indexes per tabel kunnen gebruikt worden in een selectie.
De Query analyser is "sterker" (vind ik).
En je kunt bijvoorbeeld meerdere datum-velden automatisch laten vullen in 1 tabel, dit kan MySQL bijvoorbeeld niet.

Wij gebruiken Postgres als backend database waar alle data bij elkaar komt.
En MySQL's om de grote golven feedback af te handelen, en later te syncen naar de backend Postgres database.

[ACM]

Wierdo_NL schreef op vrijdag 20 mei 2011 @ 16:45:
De Query analyser is "sterker" (vind ik).

Dat heeft niks met jouw mening te maken. Dat is in de huidige stand van zaken gewoon een feit en tot nog toe al heel lang zo (altijd?) geweest (zeker sinds PG 7.0, daarvoor wellicht ook al).

Wel is het zo dat er in MySQL ook aardig wat verbeterd is aan de query planning. Desalniettemin is PostgreSQL in mijn ervaring doorgaans wat voorspelbaarder en correcter in zijn gedrag. Dan doel ik bijvoorbeeld ook op queries die op zich correct zouden moeten zijn maar dan door een klein stukje missende functionaliteit in MySQL toch niet werken (geen limit in sommige subqueries kunnen gebruiken bijv), waarna je weer op zoek kan naar een equivalent.
Mocht je geen complexe queries doen, dan is dat allemaal niet zo relevant en kan MySQL met selects juist best sneller zijn.

[Wolfboy]

Het hangt naar mijn mening helemaal van je doel af. Als je alleen maar simpele (zonder joins of met weinig joins) selects doet zonder subqueries dan zal MySQL regelmatig sneller zijn. Zeker als je niet veel updates hebt waardoor je de query cache kan gebruiken.

Maar zodra het wat complexer wordt dan zal de Postgres query planner je een enorm voordeel geven boven MySQL. Ik heb al meermaals gehad dat een query bij MySQL door een stom queryplan minuten bezig was terwijl Postgres het binnen een fractie van een seconde deed (for the record, identieke dataset en indexen).

Daarnaast kan je met de stored procedures, custom types en triggers enorm veel doen met Postgres wat met MySQL niet/nauwelijks kan. Mijn persoonlijke keuze gaat dan ook bijna altijd uit naar MySQL, tenzij je echt heel duidelijk een eenvoudige datastore nodig hebt voor veel data met eenvoudige selects.

[EfBe]

SQL Server Express is ook gratis, en je database past daar makkelijk in, maar wel alleen windows.

De discussie begrijp ik overigens niet echt, een serieuze applicatie met veel complexe data bouw je niet bovenop een database die niet snapt wat ACID is noch wat data-integriteit is, ergo, de enige keuze uit die twee is PostgreSql.

Overigens ben je Firebird vergeten. Ook gratis, ook veel beter dan MySQL en kan ook zeker jouw data aan.

[ACM]

EfBe schreef op zaterdag 21 mei 2011 @ 09:57:
De discussie begrijp ik overigens niet echt, een serieuze applicatie met veel complexe data bouw je niet bovenop een database die niet snapt wat ACID is noch wat data-integriteit is, ergo, de enige keuze uit die twee is PostgreSql.

Dit soort commentaren zijn een beetje door de tijd ingehaald. MySQL is tegenwoordig qua stabiliteit behoorlijk vergelijkbaar met PostgreSQL.

De belangrijkste klachten mbt data-integriteit en ACID zitten 'm imho vooral in de quirkiness waarmee het allemaal werkt en het feit dat je veel van de 'features' aan moet zetten, ipv dat het standaard afgedwongen wordt. Foreign Keys aanleggen is domweg minder praktisch ingericht maar wel mogelijk (mits je weer een storage engine gebruikt die dat aan kan...), errors krijgen dat iets niet pastte in een veldje moet je expliciet aanzetten, etc.

[cariolive23]

Wierdo_NL schreef op vrijdag 20 mei 2011 @ 16:45:
De inserts mogen inderdaad langzamer zijn.

Is dat zo? De snelheid van inserts (en updates/deletes) wordt voor 99,9% bepaald door de snelheid van het opslagsysteem, de hd's. En die draaien voor een MySQL-database echt niet harder dan voor een PostgreSQL-database. PostgreSQL heeft een standaard configuratie waarbij gewacht wordt op succesvol opslaan van de data, MySQL's MyISAM (waar veel te vaak mee wordt vergeleken) kent dit hele principe niet en kan dus niet garanderen dat de data is opgeslagen.

Verder kennen PostgreSQL en innoDB een verschillend mechanisme voor transacties. PostgreSQL kun je versnellen door meerdere acties samen te voegen in één transactie, minder fsync's nodig, innoDB zal juist iets langzamer worden.

PostgreSQL en innoDB hebben beiden zo hun voor- en nadelen, maar je moet deze verschillen wel kennen om voor beiden de maximale performance er uit te slepen. Een testcase waarbij de ene duidelijk in het nadeel is t.o.v. de andere, dat heeft geen zin.


PostgreSQL is extreem betrouwbaar, ook nadat een server zonder stroom is komen te zitten: Opstarten en gaan met die banaan. PostgreSQL crasht gewoon niet, alleen kapotte schijven en/of raid controllers kunnen roet in het eten gooien. En dat heeft niets met het merk database te maken.

Ontwikkeltijd met PostgreSQL is korter, fouten komen eerder aan het licht omdat PostgreSQL geen enkele fout vergeeft: SELECT '1' + 'twee'; gaat gewoon fout. Vooral met foute GROUP BY constructies heb je hier veel aan.

Advies: PostgreSQL. Snel en betrouwbaar, wat wil je nog meer?

[Voutloos]

Altijd leuk zo'n A vs B discussie, maar een aspect dat helemaal niet behandeld word: Het lijkt erop dat jullie al meer ervaring hebben met MySQL, dus als het je verder om het even lijkt, kan dat toch gewoon de doorslag geven?

[jbdeiman]

ACM schreef op vrijdag 20 mei 2011 @ 21:27:
[...]

Mocht je geen complexe queries doen, dan is dat allemaal niet zo relevant en kan MySQL met selects juist best sneller zijn.

Het betreft een ingewikkeld systeem, en we gaan inderdaad ook complexe query's uitvoeren. Een probleem waar we nu met SQL wel eens tegenaanlopen is dat wanneer er ingewikkelde (lees: langdurige) query's worden uitgevoerd dat MySQL dat niet altijd lekker afhandelt, andere gebruikers kunnen niet / nauwelijks gebruik maken van de gebruikte tabellen in de query.

Wolfboy schreef op zaterdag 21 mei 2011 @ 03:39:
Het hangt naar mijn mening helemaal van je doel af. Als je alleen maar simpele (zonder joins of met weinig joins) selects doet zonder subqueries dan zal MySQL regelmatig sneller zijn. Zeker als je niet veel updates hebt waardoor je de query cache kan gebruiken.

Maar zodra het wat complexer wordt dan zal de Postgres query planner je een enorm voordeel geven boven MySQL. Ik heb al meermaals gehad dat een query bij MySQL door een stom queryplan minuten bezig was terwijl Postgres het binnen een fractie van een seconde deed (for the record, identieke dataset en indexen).

Daarnaast kan je met de stored procedures, custom types en triggers enorm veel doen met Postgres wat met MySQL niet/nauwelijks kan. Mijn persoonlijke keuze gaat dan ook bijna altijd uit naar MySQL, tenzij je echt heel duidelijk een eenvoudige datastore nodig hebt voor veel data met eenvoudige selects.

Zoals hierboven (reactie op bovenstaande quote) te lezen is, kunnen we niet zonder ingewikkelde query's. In de huidige methodiek die we gebruiken worden tabellen schijnbaar gelocked, waardoor andere gebruikers hier geen gebruik van kunnen maken.
Stored procedures en triggers bestaan in MySQL ook, maar zijn wellicht in Postgres wat beter?

Overigens snap ik je laatste zin niet, volgens mij bedoel je het andersom:
Mijn persoonlijke keuze gaat dan ook bijna altijd uit naar MySQL/ Postgres?, tenzij je echt heel duidelijk een eenvoudige datastore nodig hebt voor veel data met eenvoudige selects.

EfBe schreef op zaterdag 21 mei 2011 @ 09:57:
SQL Server Express is ook gratis, en je database past daar makkelijk in, maar wel alleen windows.

De discussie begrijp ik overigens niet echt, een serieuze applicatie met veel complexe data bouw je niet bovenop een database die niet snapt wat ACID is noch wat data-integriteit is, ergo, de enige keuze uit die twee is PostgreSql.

Overigens ben je Firebird vergeten. Ook gratis, ook veel beter dan MySQL en kan ook zeker jouw data aan.

Juist wegens het alleen draaien op Windows valt SQL Server Express al af. Het systeem moet op elk platform kunnen draaien.
Het gaat om een serieuze applicatie en we neigen ook naar PostgreSql, echter schijnt het (als je vergelijkingen leest) dat MySQL in strict modus prima werkt.

Firebird hebben we inderdaad laten liggen, kan je daarmee hetzelfde als PostgreSQL, bijvoorbeeld Stored Procedures, Triggers en ook foreign keys zijn erg handig? Het gaat me wat te ver om de hele documentatie door te lezen op dit soort zaken, en hoe dat geregeld is. PostgreSql ken ik (een beetje), en MySQL vrij behoorlijk.

ACM schreef op zaterdag 21 mei 2011 @ 10:56:
[...]

Dit soort commentaren zijn een beetje door de tijd ingehaald. MySQL is tegenwoordig qua stabiliteit behoorlijk vergelijkbaar met PostgreSQL.

De belangrijkste klachten mbt data-integriteit en ACID zitten 'm imho vooral in de quirkiness waarmee het allemaal werkt en het feit dat je veel van de 'features' aan moet zetten, ipv dat het standaard afgedwongen wordt. Foreign Keys aanleggen is domweg minder praktisch ingericht maar wel mogelijk (mits je weer een storage engine gebruikt die dat aan kan...), errors krijgen dat iets niet pastte in een veldje moet je expliciet aanzetten, etc.

Correct, dit noem ik ook in de TS, waarin ik aangeef dat in PostgreSql dit standaard is, in MySQL is het aan te zetten.

cariolive23 schreef op zondag 22 mei 2011 @ 13:24:
[...]

Is dat zo? De snelheid van inserts (en updates/deletes) wordt voor 99,9% bepaald door de snelheid van het opslagsysteem, de hd's. En die draaien voor een MySQL-database echt niet harder dan voor een PostgreSQL-database. PostgreSQL heeft een standaard configuratie waarbij gewacht wordt op succesvol opslaan van de data, MySQL's MyISAM (waar veel te vaak mee wordt vergeleken) kent dit hele principe niet en kan dus niet garanderen dat de data is opgeslagen.

Verder kennen PostgreSQL en innoDB een verschillend mechanisme voor transacties. PostgreSQL kun je versnellen door meerdere acties samen te voegen in één transactie, minder fsync's nodig, innoDB zal juist iets langzamer worden.

PostgreSQL en innoDB hebben beiden zo hun voor- en nadelen, maar je moet deze verschillen wel kennen om voor beiden de maximale performance er uit te slepen. Een testcase waarbij de ene duidelijk in het nadeel is t.o.v. de andere, dat heeft geen zin.

PostgreSQL is extreem betrouwbaar, ook nadat een server zonder stroom is komen te zitten: Opstarten en gaan met die banaan. PostgreSQL crasht gewoon niet, alleen kapotte schijven en/of raid controllers kunnen roet in het eten gooien. En dat heeft niets met het merk database te maken.

Ontwikkeltijd met PostgreSQL is korter, fouten komen eerder aan het licht omdat PostgreSQL geen enkele fout vergeeft: SELECT '1' + 'twee'; gaat gewoon fout. Vooral met foute GROUP BY constructies heb je hier veel aan.

Advies: PostgreSQL. Snel en betrouwbaar, wat wil je nog meer?

De snelheid van de Inserts komt uit verschillende tests tussen beide databases langzamer uit de tests, op hetzelfde systeem. Wellicht dat PostgreSql (het ging niet om de laatste versie) toen nog elke keer indexes bijwerkte, terwijl er nog 100 inserts in dezelfde query staan ofzo? Ik weet niet waarom het was, maar dit is mijn invulling van dat het trager is, of misschien wel was. Controle voor goed opslaan is natuurlijk erg prettig, maar kan e.e.a. wel trager maken.

Transacties willen we wellicht ook gaan gebruiken, is dan toch een voordeel voor PostgreSql wat voor ons wel mee gaat wegen. Het afdwingen van correcte query's is ook echt prettig, maar zoals al aangegeven kan MySQL dit ook, als je het goed configureert.

Voutloos schreef op zondag 22 mei 2011 @ 13:41:
Altijd leuk zo'n A vs B discussie, maar een aspect dat helemaal niet behandeld word: Het lijkt erop dat jullie al meer ervaring hebben met MySQL, dus als het je verder om het even lijkt, kan dat toch gewoon de doorslag geven?

Het lijkt ons om het even, en ervaring laten we vallen. Waarom:
- In de huidige omgeving is MySQL niet strict ingesteld
- Er zijn geen echte relaties tussen de tabellen, behalve die we zelf aangeven in de SELECT query's

Bij het strict instellen van MySQL moeten we op een andere manier query's bouwen (FULL GROUP BY ??)
We moeten hiervoor ons toch opnieuw verdiepen in de materie, om dit goed te doen. Met als gevolg dat we ook reëel naar andere database systemen moeten kijken.

[Wolfboy]

jbdeiman schreef op maandag 23 mei 2011 @ 10:04:
Zoals hierboven (reactie op bovenstaande quote) te lezen is, kunnen we niet zonder ingewikkelde query's. In de huidige methodiek die we gebruiken worden tabellen schijnbaar gelocked, waardoor andere gebruikers hier geen gebruik van kunnen maken.
Stored procedures en triggers bestaan in MySQL ook, maar zijn wellicht in Postgres wat beter?

De ondersteuning voor stored procedures zit al zeer lang in PostgreSQL en is nog steeds vrij nieuw in MySQL. De support is dus mogelijk minder.

Maar daarnaast heb je met Postgres bijvoorbeeld ook wat features zoals... stored procedures kan je schrijven in sql/plpgsql (oracle syntax)/perl/python/c/java/etc...

Voor zover ik zie kan je nog veel dingen niet makkelijk doen in MySQL met de stored procedures. Maar ik moet toegeven dat ik voornamelijk met de pre-stored-procedure versies van MySQL gewerkt heb. Al zie ik zo even al geen ondersteuning voor custom aggregates of "SetOf" returns. Beiden toch vaak wel handig.

Overigens snap ik je laatste zin niet, volgens mij bedoel je het andersom:
Mijn persoonlijke keuze gaat dan ook bijna altijd uit naar MySQL/ Postgres?, tenzij je echt heel duidelijk een eenvoudige datastore nodig hebt voor veel data met eenvoudige selects.

Oeps... foutje inderdaad.

Postgres heeft heel erg mijn voorkeur voor alles complexer dan "SELECT * FROM table WHERE ... ORDER BY x"

Het gaat om een serieuze applicatie en we neigen ook naar PostgreSql, echter schijnt het (als je vergelijkingen leest) dat MySQL in strict modus prima werkt.

Ik denk dat je alleen wat "features" gaat missen dan.

Deze query werkt in MySQL zonder strict mode en geeft voor c de rij terug waar "min(a)" geldt. Met strict mode geeft het een error.

MySQL:

SELECT MIN(a), b, c
FROM table
GROUP BY b

Met strict mode zou je dus zoiets moeten hebben:

MySQL:

SELECT MIN(a), b, MIN(c)
FROM table
GROUP BY b

Maar dat geeft andere resultaten, dan kan je uit 2 verschillende rijen resultaten gaan krijgen tussen a en c.

Bij PostgreSQL zou je dat oplossen met een "DISTINCT ON ()", bij MySQL kan het in strict mode niet voor zover ik weet.

[Voor 20% gewijzigd door Wolfboy op 23-05-2011 11:00]

[jbdeiman]

@Allen,

Bedankt voor de reacties. We gaan een proeftuin opzetten, om eens te kijken in hoeverre we zonder al te veel problemen met PostgreSql uit de voeten kunnen. Vooral dat we allerlei stukken daarbij kunnen programmeren, bied ons veel extra mogelijkheden.
Wanneer het niet te ingewikkeld gaat worden om de overstap te wagen, gaan we voor PostgreSql.

[cariolive23]

jbdeiman schreef op maandag 23 mei 2011 @ 10:04:
De snelheid van de Inserts komt uit verschillende tests tussen beide databases langzamer uit de tests, op hetzelfde systeem.

Heb je ook een link naar dit testgeval? Zonder de exacte test te kennen, zegt het resultaat erg weinig.

Dit:
INSERT ...;
INSERT ...;

is bijna 2x langzamer dan:
BEGIN;
INSERT ...;
INSERT ...;
COMMIT;

In de eerste geval zul je 2x een fsync voorbij zien komen, in het tweede geval slechts 1x. En omdat een hardeschijf slechts een X-aantal fsync's per seconde kan uitvoeren, zul hier dus altijd tegen een plafond aanlopen. Ook met MySQL wanneer deze met innoDB een fsync gaat afdwingen van het OS.

Wanneer het niet belangrijk is of de data ook daadwerkelijk is opgeslagen, kun je ook in PostgreSQL de fsync uitzetten, dan gaan de insert's en update's ook direct een héél stuk sneller. Bij een crash van de server kun je dan alleen wel data kwijt raken, dat is logisch en daar kies je zelf voor. Dat is met iedere database het geval wanneer de data nog niet is opgeslagen.

Controle voor goed opslaan is natuurlijk erg prettig, maar kan e.e.a. wel trager maken.

Zoals reeds gezegd, dat kun je ook uitzetten. Mocht de data onbelangrijk zijn en de performance extreem belangrijk zonder dat je voldoende budget hebt voor snellere systemen.

Bedenk wel dat met een slimme aanpak van de insert's en update's, de schrijfperformance gewoon goed kan zijn. Ik heb hier een database draaien die al een jaar zo'n 5000 insert's per seconde doet, op een RAID5 met 6 schijven die slechts 7200 toeren draaien (HP DL380-server). De 2.5TB (6x500GB) zal dit jaar vol zitten, dat is de enige reden om naar andere/extra opslag te kijken, voor de performance (ook de complexe select's) is het niet nodig.

[Wolfboy]

cariolive23 schreef op maandag 23 mei 2011 @ 20:40:
Wanneer het niet belangrijk is of de data ook daadwerkelijk is opgeslagen, kun je ook in PostgreSQL de fsync uitzetten, dan gaan de insert's en update's ook direct een héél stuk sneller. Bij een crash van de server kun je dan alleen wel data kwijt raken, dat is logisch en daar kies je zelf voor. Dat is met iedere database het geval wanneer de data nog niet is opgeslagen.

Imho zeer slecht advies. fsync uitzetten geeft je een beetje performance winst maar als je het uitzet ben je nagenoeg zeker van corruptie na een crash.

Aangezien je wal_sync_method kan instellen op een snellere/betere methode is dat sowieso een betere optie. Afhankelijk van je OS en filesystem open_sync, open_datasync or fsync_writethrough gebruiken gaat ook heel veel helpen.

En anders kan je nog een raid kaart met write cache nemen.

[cariolive23]

Wolfboy schreef op maandag 23 mei 2011 @ 22:14:
[...]
Imho zeer slecht advies.

Dat klopt helemaal, het is ook een beroerd advies. Maar dat is wel wat velen willen horen, ze vergelijken niet voor niets een onbekende test die hoogstwaarschijnlijk met MyISAM en/of een standaard MySQL-configuratie met een standaard PostgreSQL-configuratie. En dan is PostgreSQL altijd langzamer, fsync kost nu eenmaal tijd.

fsync uitzetten geeft je een beetje performance winst maar als je het uitzet ben je nagenoeg zeker van corruptie na een crash.

Exact, en dikke kans dat na een crash de databaseservice zelfs niet meer wil starten.

En anders kan je nog een raid kaart met write cache nemen.

Zodra de cache volzit, ga je nog steeds merken dat fsync tijd kost. Er zijn nu gelukkig wel betaalbare kaarten te krijgen met 1GB cache, dat is in vele gevallen meer dan genoeg. Het kost een paar honderd euro, maar dan heb je ook wat.

[EfBe]

jbdeiman schreef op maandag 23 mei 2011 @ 10:04:
Juist wegens het alleen draaien op Windows valt SQL Server Express al af. Het systeem moet op elk platform kunnen draaien.
Het gaat om een serieuze applicatie en we neigen ook naar PostgreSql, echter schijnt het (als je vergelijkingen leest) dat MySQL in strict modus prima werkt.

Tja, het is jouw applicatie. PostgreSql is gemaakt door mensen die snappen wat telt in een RDBMS. MySQL heeft nooit laten zien dat de mensen die het maken ook daadwerkelijk verstand hebben wat belangrijk is in een RDBMS.

Firebird hebben we inderdaad laten liggen, kan je daarmee hetzelfde als PostgreSQL, bijvoorbeeld Stored Procedures, Triggers en ook foreign keys zijn erg handig? Het gaat me wat te ver om de hele documentatie door te lezen op dit soort zaken, en hoe dat geregeld is. PostgreSql ken ik (een beetje), en MySQL vrij behoorlijk.

Firebird zou ik altijd boven MySQL kiezen. Zeker de huidige versie is zeer compleet. Stored procs, triggers, FKs etc. het zit er allemaal in.

Overigens erger ik me wel een beetje, en dat is aan het 'het moet gratis'. Als je applicatie zo serieus is en zo belangrijk, dan is 'het moet gratis' totaal niet van belang want je kiest dan de beste DB die er is. Of die dan geld kost is bijzaak. Ook de focus op MySQL snap ik niet. MySQL heeft al jaren laten zien dat het niet bedoeld is voor serieuze data opslag, het laat gewoon steken vallen. Als je een serieuze applicatie maakt, dan valt die database meteen af. Er nog langer over praten geeft mij iig de indruk dat je applicatie niet zo serieus is als je doet voorkomen.

[Voor 10% gewijzigd door EfBe op 24-05-2011 09:11]

[Remus]

jbdeiman schreef op maandag 23 mei 2011 @ 10:04:
[...]

Firebird hebben we inderdaad laten liggen, kan je daarmee hetzelfde als PostgreSQL, bijvoorbeeld Stored Procedures, Triggers en ook foreign keys zijn erg handig? Het gaat me wat te ver om de hele documentatie door te lezen op dit soort zaken, en hoe dat geregeld is. PostgreSql ken ik (een beetje), en MySQL vrij behoorlijk.

Firebird heeft stored procedures, triggers, foreign keys, compound indices, check constraints, domains en is in staat om meerdere indices in een query te gebruiken. Firebird heeft sinds recente versies ook de zeer handige Common Table Expressions (CTE).

Een nadeel van Firebird is dat de documentatie nogal gefragmenteerd is: de basis documentatie is van Interbase 6.0 van eind jaren negentig (toen Firebird werd geforked van het toen opensourced (nu weer closedsourced) interbase). Veranderingen sindsdien zijn gedocumenteerd in een Language Reference Update waardoor het overzicht soms wat moeilijk is.
Een voordeel is wel dat de community erg behulpzaam is (waarbij zelfs mensen betrokken zijn die begin jaren 80 betrokken waren bij de ontwikkeling van de eerste versie).

[jbdeiman]

EfBe schreef op dinsdag 24 mei 2011 @ 09:06:
[...]

Tja, het is jouw applicatie. PostgreSql is gemaakt door mensen die snappen wat telt in een RDBMS. MySQL heeft nooit laten zien dat de mensen die het maken ook daadwerkelijk verstand hebben wat belangrijk is in een RDBMS.


[...]

Firebird zou ik altijd boven MySQL kiezen. Zeker de huidige versie is zeer compleet. Stored procs, triggers, FKs etc. het zit er allemaal in.

Overigens erger ik me wel een beetje, en dat is aan het 'het moet gratis'. Als je applicatie zo serieus is en zo belangrijk, dan is 'het moet gratis' totaal niet van belang want je kiest dan de beste DB die er is. Of die dan geld kost is bijzaak. Ook de focus op MySQL snap ik niet. MySQL heeft al jaren laten zien dat het niet bedoeld is voor serieuze data opslag, het laat gewoon steken vallen. Als je een serieuze applicatie maakt, dan valt die database meteen af. Er nog langer over praten geeft mij iig de indruk dat je applicatie niet zo serieus is als je doet voorkomen.

Data integriteit is zeer belangrijk, dus we gaan fsync niet uitzetten.

Dat jij je ergert aan dat het "gratis moet zijn" moet je helemaal zelf weten, ik heb in de TS uitgelegd wat het beleid hierop is:

Een paar vallen al af (betaald, omdat het hele idee van het pakket is dat het zonder bijkomende kosten moet kunnen draaien

We willen klanten naast ons pakket niet opzadelen met extra kosten van een verplicht ander software pakket wanneer ze de applicatie (web applicatie) op een eigen interne server willen draaien. Dit is beleid en is altijd zo geweest, Dat we dus betaalde systemen om deze reden af laten vallen mag hierdoor een duidelijke reden hebben. Ook bij serieuze applicaties wordt gewoon beleid gemaakt, er is bij ons beleid (overigens niet door mij bedacht) voor gekozen om rekening te houden met kosten van klanten, en deze naast de aanschaf van de applicatie niet op te zadelen met extra licenties.

Remus schreef op woensdag 25 mei 2011 @ 08:48:
[...]

Firebird heeft stored procedures, triggers, foreign keys, compound indices, check constraints, domains en is in staat om meerdere indices in een query te gebruiken. Firebird heeft sinds recente versies ook de zeer handige Common Table Expressions (CTE).

Een nadeel van Firebird is dat de documentatie nogal gefragmenteerd is: de basis documentatie is van Interbase 6.0 van eind jaren negentig (toen Firebird werd geforked van het toen opensourced (nu weer closedsourced) interbase). Veranderingen sindsdien zijn gedocumenteerd in een Language Reference Update waardoor het overzicht soms wat moeilijk is.
Een voordeel is wel dat de community erg behulpzaam is (waarbij zelfs mensen betrokken zijn die begin jaren 80 betrokken waren bij de ontwikkeling van de eerste versie).

Oké, weet ik wel even genoeg van Firebird denk ik. Het kan alles wel, maar we moeten ook zelfredzaam zijn in het ontwikkelen, en niet afhankelijk zijn van vragen die we op de community stellen, gefragmenteerde documentatie kost nu eenmaal veel meer tijd en (zoals het overal gaat) tijd == geld.

Wel de moeite waard om wanneer we in rustigere tijden zitten vwbt allerlei wettelijke verplichtingen aan de applicatie, eens goed naar te gaan kijken.

[Voor 25% gewijzigd door jbdeiman op 25-05-2011 09:15]

[kwaakvaak_v2]

Maar... Welke storage engine gebruik je in mySQL? Want innoDB of MYisam scheelt nogal een slok op een paar borrels

innoDB is bijvoorbeeld wel volledig ACID compliant met transacties etc. Tuurlijk vereist dit wel dat je sql laag in je applicatie hier mee om moet kunnen gaan en queries zoals cariolive hierboven meldt wel netjes met een begin transaction, commit -> fail = rollback manier moet versturen en niet overal in de applicatie een query doen waar het uitkomt.

Goede performance begint in je applicatie laag imho en niet in je DB laag. Natuurlijk speelt die ook wel een rol, maar als je code erboven van het type bordje spaghetti is dan maakt het geen fluit uit waar je de data naar toe schrijft.

Maar als jij nu in je applicatie een plugable sql storage laag stopt, zoals in php door o.a.Doctrine2 wordt aangeboden, kun je de queries gewoon generiek schrijven en je mogelijke klant zelf laten bepalen welke db laag die er onder zet. En desgewenst kan er dan ook gebruik gemaakt worden van Oracle, MSSQL, noSQL oplossingen als je hip wilt doen, of desnoods een IBM iSeries als je echt geld wilt uitgeven. Mits je driver dit ondersteund.

[Voor 23% gewijzigd door kwaakvaak_v2 op 25-05-2011 10:12. Reden: extra stukje]

[jbdeiman]

kwaakvaak_v2 schreef op woensdag 25 mei 2011 @ 10:07:
Maar... Welke storage engine gebruik je in mySQL? Want innoDB of MYisam scheelt nogal een slok op een paar borrels

innoDB is bijvoorbeeld wel volledig ACID compliant met transacties etc. Tuurlijk vereist dit wel dat je sql laag in je applicatie hier mee om moet kunnen gaan en queries zoals cariolive hierboven meldt wel netjes met een begin transaction, commit -> fail = rollback manier moet versturen en niet overal in de applicatie een query doen waar het uitkomt.

Goede performance begint in je applicatie laag imho en niet in je DB laag. Natuurlijk speelt die ook wel een rol, maar als je code erboven van het type bordje spaghetti is dan maakt het geen fluit uit waar je de data naar toe schrijft.

Maar als jij nu in je applicatie een plugable sql storage laag stopt, zoals in php door o.a.Doctrine2 wordt aangeboden, kun je de queries gewoon generiek schrijven en je mogelijke klant zelf laten bepalen welke db laag die er onder zet. En desgewenst kan er dan ook gebruik gemaakt worden van Oracle, MSSQL, noSQL oplossingen als je hip wilt doen, of desnoods een IBM iSeries als je echt geld wilt uitgeven. Mits je driver dit ondersteund.

We gebruiken de InnoDB engine uiteraard, vanwege de betere betrouwbaarheid. Maar qua query'ing (ingewikkelde query's die we soms wel moeten doen) zijn er betere/ snellere oplossingen dan MySQL.

Een pluggable laag is wel een leuk idee, maar we willen (ook vanwege dat een deel van onze klanten op onze server werkt, dus als een ASP oplossing) wel een standaard systeem hebben om mee te werken, en wat we klanten ook met een "gerust hart" kunnen adviseren, ongeacht het besturingssysteem waar de klant mee werkt.

Overigens zitten er ook nadelen aan, omdat niet alle mogelijkheden van de 1e database in een ander ook ondersteund worden. Hier moeten we dan een workarround voor bedenken.
Op zich mogelijk, maar wel iets waar we voorzichtig mee zijn.

[kwaakvaak_v2]

Een pluggable laag is wel een leuk idee, maar we willen (ook vanwege dat een deel van onze klanten op onze server werkt, dus als een ASP oplossing) wel een standaard systeem hebben om mee te werken, en wat we klanten ook met een "gerust hart" kunnen adviseren, ongeacht het besturingssysteem waar de klant mee werkt.

Sinds wanneer bepaalt een plugable laag in je code, op welk besturingsysteem iets draait? Het bepaalt hooguit welke taal je, je applicatie in maakt. Maar aangezien het over een webapplicatie gaat gok ik dat het PHP is. En dat werkt prima op zo'n beetje elk OS wat ik tot op heden tegen ben gekomen, inclusief jawel, een iSeries/AS/400. De datalaag zorgt ervoor dat de query netjes vertaald wordt naar een query die de database server begrijpt.

Nogmaals goede performance is meer dan zorgen dat je snelle SQL server hebt. Ook dingen in memory cachen, of desnoods temp tables/materialized views etc kunnen bepalend zijn voor de snelheid van je applicatie. De SQL server is maar een relatief klein onderdeel van een geheel.

[Voor 15% gewijzigd door kwaakvaak_v2 op 25-05-2011 10:28]

[jbdeiman]

kwaakvaak_v2 schreef op woensdag 25 mei 2011 @ 10:26:
[...]


Sinds wanneer bepaalt een plugable laag in je code, op welk besturingsysteem iets draait? Het bepaalt hooguit welke taal je, je applicatie in maakt. Maar aangezien het over een webapplicatie gaat gok ik dat het PHP is. En dat werkt prima op zo'n beetje elk OS wat ik tot op heden tegen ben gekomen, inclusief jawel, een iSeries/AS/400. De datalaag zorgt ervoor dat de query netjes vertaald wordt naar een query die de database server begrijpt.

Nogmaals goede performance is meer dan zorgen dat je snelle SQL server hebt. Ook dingen in memory cachen, of desnoods temp tables/materialized views etc kunnen bepalend zijn voor de snelheid van je applicatie. De SQL server is maar een relatief klein onderdeel van een geheel.

Volgens mij begrijpen we elkaar niet, ik ben het met je eens dat de database maar een deel van het geheel is. Echter kan je query's wel aanpassen op verschillende databases, door een plugable laag, maar dat wil niet zeggen dat de methoden die je gebruikt voor de 1e database (en dan doel ik met name op triggers, e.d. die wel een wezenlijk onderdeel kunnen zijn van een systeem) ook werken in een ander.

Het draait overigens inderdaad op PHP, maar er wordt heel wat data voor langere tijd in opgeslagen. Het gaat hier niet alleen om de snelheid, al pak ik dat nu op het einde wel meer op als mogelijke reden, maar het gaat vooral om betrouwbaarheid van de data en het systeem als geheel.
Als we in (bijvoorbeeld) PostgreSql een goed/ betrouwbaar systeem met triggers hebben, werkt dat niet zomaar in MySQL, omdat triggers daar heel anders in elkaar zitten, en als vanzelf dus niet op dezelfde manier werken. Het gebruiken van meerdere SQL databases zal dus problemen kunnen opleveren, tenzij we zelf een soortgelijke constructie maken voor een andere database, zodat we toch weer buiten de DB om gaan werken. Het grootste probleem met de huidige lopende versie van de applicatie is juist dat we heel veel buiten de daatabase om proberen af te vangen en te regelen, terwijl het sneller en betrouwbaarder is om dit wel te laten afhandelen op de plek waar het moet gebeuren:
De database.

Zoals bijvoorbeeld een waarde die ergens wordt aangepast, wat gevolgen heeft voor een aantal andere plekken (in ons geval: een cliënt overlijdt) => Dit betekend dat er ongeveer 20 acties gedaan moeten worden (dit heeft niets met normaliseren te maken overigens) waarbij de overlijdensdatum leidend is voor het stopzetten van een product, de huur van een kamer enzovoorts. Met een trigger, en/ of een transactie werkt dit prima, en snel en betrouwbaar.
Echter wordt dit niet altijd (lees: door alle SQL servers) op de correcte manier ondersteund. Wanneer je voor betrouwbaarheid wil gaan kies je een betrouwbare SQL server, en ga je niet omwille van de keuze vrijheid alle mogelijke SQL servers ondersteunen. Soms moet je keuzes maken, en dan wil je wel dat dit een goede (en onderbouwde) keuze is.

[EfBe]

jbdeiman schreef op woensdag 25 mei 2011 @ 10:52:
[...]
Het draait overigens inderdaad op PHP, maar er wordt heel wat data voor langere tijd in opgeslagen. Het gaat hier niet alleen om de snelheid, al pak ik dat nu op het einde wel meer op als mogelijke reden, maar het gaat vooral om betrouwbaarheid van de data en het systeem als geheel.
Als we in (bijvoorbeeld) PostgreSql een goed/ betrouwbaar systeem met triggers hebben, werkt dat niet zomaar in MySQL, omdat triggers daar heel anders in elkaar zitten, en als vanzelf dus niet op dezelfde manier werken. Het gebruiken van meerdere SQL databases zal dus problemen kunnen opleveren, tenzij we zelf een soortgelijke constructie maken voor een andere database, zodat we toch weer buiten de DB om gaan werken. Het grootste probleem met de huidige lopende versie van de applicatie is juist dat we heel veel buiten de daatabase om proberen af te vangen en te regelen, terwijl het sneller en betrouwbaarder is om dit wel te laten afhandelen op de plek waar het moet gebeuren:
De database.

Aloude discussie, maar je gaat voorbij aan het feit dat een database zelf geen dingen start, de applicatie doet dat. Je kunt wel veel in triggers stoppen maar feitelijk komt dat op hetzelfde neer als dat je in je applicatie zorgt dat een X aantal taken in dezelfde transaction worden afgehandeld, immers: een taak X heeft een Y aantal stappen en die voer je uit van start tot end. Wegstoppen in triggers lijkt makkelijk maar komt de onderhoudbaarheid niet ten goede.

Zoals bijvoorbeeld een waarde die ergens wordt aangepast, wat gevolgen heeft voor een aantal andere plekken (in ons geval: een cliënt overlijdt) => Dit betekend dat er ongeveer 20 acties gedaan moeten worden (dit heeft niets met normaliseren te maken overigens) waarbij de overlijdensdatum leidend is voor het stopzetten van een product, de huur van een kamer enzovoorts. Met een trigger, en/ of een transactie werkt dit prima, en snel en betrouwbaar.

Ook met een procedure of gewoon een stuk code buiten de applicatie die afhandelt dat iemand overlijdt kan dit prima worden opgelost.

Echter wordt dit niet altijd (lees: door alle SQL servers) op de correcte manier ondersteund. Wanneer je voor betrouwbaarheid wil gaan kies je een betrouwbare SQL server, en ga je niet omwille van de keuze vrijheid alle mogelijke SQL servers ondersteunen. Soms moet je keuzes maken, en dan wil je wel dat dit een goede (en onderbouwde) keuze is.

Dit begrijp ik niet. Wat is een 'onbetrouwbare SQL server' ? Je hebt databases die 100% data integriteit waarborgen en full ACID compliant zijn en je hebt MySQL en andere 'databases' die af en toe steken laten vallen, of niet full ACID compliant zijn. Dus wil je betrouwbare dataopslag dan kies je een database die dat ook kan, dus wanneer de transaction terugrolt, dat die dan ook 100% terugrolt en wanneer deze commit dat alles dan ook gecommit is.

Dat je nog steeds geen keuze hebt gemaakt riekt naar het feit dat je nog steeds aan het zoeken bent naar redenen om toch MySQL te gebruiken. Je schuift firebird aan de kant alsof deze niet volwassen is, terwijl je wel wilt praten over MySQL die een slechtere ACID compliance heeft dan MS Access...

[jbdeiman]

EfBe schreef op woensdag 25 mei 2011 @ 12:59:
[...]

Aloude discussie, maar je gaat voorbij aan het feit dat een database zelf geen dingen start, de applicatie doet dat. Je kunt wel veel in triggers stoppen maar feitelijk komt dat op hetzelfde neer als dat je in je applicatie zorgt dat een X aantal taken in dezelfde transaction worden afgehandeld, immers: een taak X heeft een Y aantal stappen en die voer je uit van start tot end. Wegstoppen in triggers lijkt makkelijk maar komt de onderhoudbaarheid niet ten goede.


[...]

Ook met een procedure of gewoon een stuk code buiten de applicatie die afhandelt dat iemand overlijdt kan dit prima worden opgelost.


[...]

Dit begrijp ik niet. Wat is een 'onbetrouwbare SQL server' ? Je hebt databases die 100% data integriteit waarborgen en full ACID compliant zijn en je hebt MySQL en andere 'databases' die af en toe steken laten vallen, of niet full ACID compliant zijn. Dus wil je betrouwbare dataopslag dan kies je een database die dat ook kan, dus wanneer de transaction terugrolt, dat die dan ook 100% terugrolt en wanneer deze commit dat alles dan ook gecommit is.

Dat je nog steeds geen keuze hebt gemaakt riekt naar het feit dat je nog steeds aan het zoeken bent naar redenen om toch MySQL te gebruiken. Je schuift firebird aan de kant alsof deze niet volwassen is, terwijl je wel wilt praten over MySQL die een slechtere ACID compliance heeft dan MS Access...

Wedervraag:
Lees je wel wat ik er als reden bij geef? Volgens mij niet als ik je reactie zo lees, Firebird kenden we nog niet en het feit dat wordt aangedragen over slechte/ verspreide documentatie maakt dat het voor ons niet handig is. Het moet (ook voor toekomstige medewerkers) wel enigszins mogelijk zijn met beschikbare documentatie eenvoudig uit de voeten te kunnen met een systeem. Dat is bij Firebird volgens aangedragen redenen (nee, deze heb ik dus niet zelf verzonnen) niet het geval.
Ik schuif het niet aan de kant omdat het geen goed systeem zou zijn, maar omdat de zelfredzaamheid bij problemen lager ligt, ivm het niet goed beschikbaar zijn van die documentatie. Wederom, dit is gebaseerd op aangedragen redenen!

Ook heb ik al aangegeven dat we willen spelen met PostgreSQL, om die mogelijk te gaan gebruiken. We zoeken geen redenen om MySQL te blijven gebruiken, we zoeken juist (goede!) redenen om hier verandering in te brengen. Verandering is altijd moeilijk, zonder goede reden/ onderbouwing gaat dat ook niet lukken.

Voor wat betreft triggers heb ik denk ik ook geen goed voorbeeld gebruikt, maar triggers kunnen een enorme toegevoegde waarde hebben. Daarnaast heb je ook nog functies die je kan aanroepen en aanmaken voor PostgreSQL, ook dat is wel prettig en maakt werken hiermee wel eenvoudiger.

Maar omdat dit niet overal kan op eenzelfde manier is het niet mogelijk als je alle typen databases wil ondersteunen (voorbeeld werd gegeven, met een class ertussen voor de koppeling/ het omzetten van de query's naar het juiste format in een andere database) zou je alweer moeten uitwijken naar een andere methode.
Ook wij snappen wel dat het qua onderhoudbaarheid misschien minder praktisch kan zijn, daarom geef ik ook aan dat het misschien niet helemaal een goed voorbeeld is. Er zijn wel degelijk situaties waarbij het wel handig is om dit vanuit de database af te handelen, in plaatst van steeds te schakelen tussen database en server side PHP code.

Als ik wat kortaf reageer komt dat omdat je mij woorden in de mond legt die geenszins waar zijn, ik wil juist liever een andere database gebruiken, maar dan moeten daar wel goede redenen voor zijn en moeten we onszelf kunnen redden, qua documentatie. Dus dat we bepaalde zaken wel eenvoudig terug kunnen vinden.

[kwaakvaak_v2]

terwijl je wel wilt praten over MySQL die een slechtere ACID compliance heeft dan MS Access...

Onzin!... kom eens met recente feiten, en niet op uit verleden gebaseerde feiten!


Maar als voor de TS het belangrijk is dat zijn applicatie draait op zowel eigen hardware, als hardware van de klant dan lijkt mij de keuze voor postgresql minder voor de hand liggend dan mysql. Al was het alleen maar omdat de meeste VPS hosters standaard een LAMP stack aanbieden, en zelden een LAPP stack.

Zoals bijvoorbeeld een waarde die ergens wordt aangepast, wat gevolgen heeft voor een aantal andere plekken (in ons geval: een cliënt overlijdt) => Dit betekend dat er ongeveer 20 acties gedaan moeten worden (dit heeft niets met normaliseren te maken overigens) waarbij de overlijdensdatum leidend is voor het stopzetten van een product, de huur van een kamer enzovoorts. Met een trigger, en/ of een transactie werkt dit prima, en snel en betrouwbaar.

Lijkt mij typisch iets wat niet perse realtime hoeft te gebeuren, en kan dus prima in een worker worden afgehandeld. Feit is de persoon dood is, en als dat maar binnen een redelijke termijn in het systeem verwerkt is. Je 'flagged' het persoonsrecord als 'overleden' met een datetimestamp, en je worker verwerkt dat later in het systeem.

Mijn eerste statement blijft gewoon staan,goede performance begint in je applicatie, niet in de onderliggende DB engine.

Triggers zijn leuk, maar niet noodzakelijk, plus lastiger te implementeren in je applicatie laag. Want hoe ga je meten als je trigger om wat voor reden dan ook mislukt? Of ga je dan gewoon een loop in net zo lang tot het lukt, met mogelijke deadlock? Workers via een semaphore/mutext lock systeem kunnen gewoon loggen als er iets mis gaat, en desnoods eindeloos blijven proberen ipv je applicatie te laten sterven.

Als consistentie en snelheid echt zo belangrijk zijn moet je eerst een beginnen in je datamodel aan te geven wat realtime moet, en wat later kan.

[Voor 3% gewijzigd door kwaakvaak_v2 op 25-05-2011 13:38. Reden: zin afgemaakt ;(]

[Remus]

jbdeiman schreef op woensdag 25 mei 2011 @ 13:24:
[...]

Firebird kenden we nog niet en het feit dat wordt aangedragen over slechte/ verspreide documentatie maakt dat het voor ons niet handig is.

Laat ik vooropstellen dat de documentatie van Firebird niet slecht is. Het probleem is echter wel dat documentatie van nieuwe en gewijzigde functionaliteit apart staat van de documentatie van de functionaliteit die al bestond in interbase 6.0. Dit heeft voornamelijk te maken met een gebrek aan mankracht om de gehele documentatie opnieuw te schrijven (de Interbase 6.0 documentatie mag wel in huidige vorm gedistribueerd worden, maar het Firebird project mag diezelfde documentatie om copyright redenen niet gebruiken als uitgangspunt voor nieuwe versies van documentatie voor Firebird).

[jbdeiman]

kwaakvaak_v2 schreef op woensdag 25 mei 2011 @ 13:31:
[...]


Onzin!... kom eens met recente feiten, en niet op uit verleden gebaseerde feiten!


Maar als voor de TS het belangrijk is dat zijn applicatie draait op zowel eigen hardware, als hardware van de klant dan lijkt mij de keuze voor postgresql minder voor de hand liggend dan mysql. Al was het alleen maar omdat de meeste VPS hosters standaard een LAMP stack aanbieden, en zelden een LAPP stack.


[...]


Lijkt mij typisch iets wat niet perse realtime hoeft te gebeuren, en kan dus prima in een worker worden afgehandeld. Feit is de persoon dood is, en als dat maar binnen een redelijke termijn in het systeem verwerkt is. Je 'flagged' het persoonsrecord als 'overleden' met een datetimestamp, en je worker verwerkt dat later in het systeem.

Mijn eerste statement blijft gewoon staan,goede performance begint in je applicatie, niet in de onderliggende DB engine.

Triggers zijn leuk, maar niet noodzakelijk, plus lastiger te implementeren in je applicatie laag. Want hoe ga je meten als je trigger om wat voor reden dan ook mislukt? Of ga je dan gewoon een loop in net zo lang tot het lukt, met mogelijke deadlock? Workers via een semaphore/mutext lock systeem kunnen gewoon loggen als er iets mis gaat, en desnoods eindeloos blijven proberen ipv je applicatie te laten sterven.

Als consistentie en snelheid echt zo belangrijk zijn moet je eerst een beginnen in je datamodel aan te geven wat realtime moet, en wat later kan.

Heb je een punt, zoals ik al zei is het misschien een slecht voorbeeld. Het kan wel een heel prettige toevoeging zijn om iets dergelijks te gebruiken, maar is niet noodzakelijk. Als we toch 1 keuze maken kan het systeem wel versneld worden door het gebruik van soortgelijke constructies.

Het datamodel wordt adhv wat we nu weten, (10 jaar geleden) met de sector waar we de applicatie voor maken, volledig herschreven. Wellicht dat een reeks van functies die aangeroepen wordt ook een handige optie is, maar daar komen we later op.

Overigens voor wat betreft de ASP oplossing, of wij hosten bij onze provider (90 % van de klanten) zodat men via internet rechtstreeks op de applicatie kan (wel HTTPS) of ze hosten het intern bij henzelf, op een interne eigen server, waarvoor ze van ons horen wat randvoorwaarden zijn voor het werken op een eigen interne server.

Een andere voorwaarde die trouwens bij verschillende systemen beschikbaar is is master/slave replication. Dit is ook een wenselijke eis aan de database.

[cariolive23]

EfBe schreef op dinsdag 24 mei 2011 @ 09:06:
[...]
Overigens erger ik me wel een beetje, en dat is aan het 'het moet gratis'. Als je applicatie zo serieus is en zo belangrijk, dan is 'het moet gratis' totaal niet van belang want je kiest dan de beste DB die er is. Of die dan geld kost is bijzaak.

Mijn leven is 100x belangrijker dan welke database dan ook, maar toch rijd ik niet in de meest veilige auto. Waarom niet? Omdat ik daar het geld niet voor heb, ook niet wanneer de kosten blijkbaar bijzaak zijn.

Een project heeft een budget en wanneer dat al opgaat aan andere kosten, blijft er nul komma niks over voor de licentiekosten. Niks bijzonders en ook geen enkel probleem: Er zijn voldoende databases beschikbaar die standaard DBMS-functionaliteit in huis hebben.

En wat is "de beste DB die er is" ? Zoveel mensen, zoveel meningen. Komt bij dat er in dit topic maar een handvol requirements worden genoemd, daarmee wordt het lastig om "de beste DB" vast te stellen. PostgreSQL voldoet voor grote en kleine organistaties, is snel, uitstekende concurrency, goede documentatie, kost nul komma niks aan licentiekosten en draait op vrijwel ieder OS.

[BCC]

De enige manier om te bepalen of de ene database 'beter' is dan een een andere is door te benchmarken met productiegegevens.

Als je dat nog niet kan omdat je nog een nieuw product aan het ontwikkelen bent, moet je een voorspelling proberen te maken over wat jouw product in de toekomst gaat doen.

1) Waar moet het later gaan draaien? Bij de klant, of ga je het zelf hosten of uitbesteden?
2) Heb je specifieke features nodig of een domme data store? Postgres heeft bijvoorbeeld PostGis waarmee je eenvoudig coole dingen kunt toen met geodata.
3) Hoe gaan de licentiekosten zich in de toekomst ontwikkelen? Bijna alle databases zijn voor kleine installaties nagenoeg gratis. Als je grotere omgevingen hebt, met meerdere machines en supportcontracten, dan gaat de teller lopen. Let hierbij vooral even op dat MySQL recent door Oracle is overgenomen en het dus onduidelijk is wat er met de licentiekosten gaat gebeuren. Aan de andere kant biedt Amazon het nu aan voor zeer weinig geld. Geen enkele database is in een professionele omgeving gratis. Mysql support is bijvoorbeeld veel makkelijker te vinden dan Postgres support. MSSQL support is nog goedkoper, maar de licentiekosten stijgen bij groei zo'n beetje exponentieel.

Zoals hierboven al genoemd, is Mysql ontstaan uit de filosofie om zo snel mogelijk data te leveren en Postgres om zo correct mogelijk data te leveren. Tegenwoordig zijn beide echter volwaardige DBMS systemen die elkaar op de meeste gebieden weinig ontlopen.

[Voor 13% gewijzigd door BCC op 25-05-2011 18:34]

[ACM]

BCC schreef op woensdag 25 mei 2011 @ 18:18:
De enige manier om te bepalen of de ene database 'beter' is dan een een andere is door te benchmarken met productiegegevens.

Dan weet je alleen maar welke sneller is. Of was je van plan ook diverse malen tijdens je benchmark de stekker uit je server te trekken om te zien welke het beste tegen crashes bestand is? En ga je de benchmark ook zwaarder maken om zo schaalbaarheid te testen?

De performance benchmarken is soms overbodig als je 'snel genoeg' hebt vastgesteld. En soms is de performance benchmarken heel belangrijk Maar het is niet de enige manier om vast te stellen welke het beste is. Je zal domweg harde en softe requirements moeten opstellen en kijken welke database er het beste bij aansluit.

[cariolive23]

BCC schreef op woensdag 25 mei 2011 @ 18:18:
Geen enkele database is in een professionele omgeving gratis.

Licentie en support zijn twee verschillende dingen, support is nooit gratis, de licentie kan wel gratis zijn.

Mysql support is bijvoorbeeld veel makkelijker te vinden dan Postgres support.

Dit zegt niks, ik mag nog wel eens een overleden MySQL-server tot leven wekken dankzij iets te gemakkelijk gevonden "support". Iemand van de wal in de sloot helpen is ook hulp, maar of je daar nu echt op zit te wachten?

MSSQL support is nog goedkoper

Kun je dat met cijfers aantonen? Dit is wel een zeer generieke uitspraak. Of je moet het weer over de prutsers hebben, die zijn inderdaad erg goedkoop.

Zoals hierboven al genoemd, is Mysql ontstaan uit de filosofie om zo snel mogelijk data te leveren en Postgres om zo correct mogelijk data te leveren. Tegenwoordig zijn beide echter volwaardige DBMS systemen die elkaar op de meeste gebieden weinig ontlopen.

Elkaar weinig ontlopen? Op functioneel gebied ligt PostgreSQL al straatlengtes voor op MySQL. Denk aan de vele datatypes, recursieve queries, windowing functions, functionele indexen, PL/Perl en andere PL-talen, zeer goede full text search, subqueries die overal simpel zijn in te zetten, etc. etc. Het enige waar MySQL beter in is, is de wat eenvoudiger in te richten replicatie en voor de ene keer dat een index-only scan wel handig is. Wat beheer betreft heb je geen kind aan PostgreSQL, dat werkt gewoon, ook na een verstoring, MySQL is nog steeds een zorgenkindje wanneer er verstoringen optreden.

[Wolfboy]

cariolive23 schreef op woensdag 25 mei 2011 @ 22:56:
Elkaar weinig ontlopen? Op functioneel gebied ligt PostgreSQL al straatlengtes voor op MySQL. Denk aan de vele datatypes, recursieve queries, windowing functions, functionele indexen, PL/Perl en andere PL-talen, zeer goede full text search, subqueries die overal simpel zijn in te zetten, etc. etc. Het enige waar MySQL beter in is, is de wat eenvoudiger in te richten replicatie en voor de ene keer dat een index-only scan wel handig is. Wat beheer betreft heb je geen kind aan PostgreSQL, dat werkt gewoon, ook na een verstoring, MySQL is nog steeds een zorgenkindje wanneer er verstoringen optreden.

Dan vergeet je nog dingen zoals:
[list]• Custom datatypes (die je eenvoudig zelf kan maken)
• Strong typing met zelf configureerbare casting mogelijkheden naar andere typen
• Table inheritance
• Partial index (index met where clause om ze kleiner te houden)
• Clusteren op indexes
• Custom aggregate functies
• Custom indexes (bijvoorbeeld de geografische indexes)
• Genetische query optimizer voor _echt_ lastige queries


Overigens is sinds Postgres 9 ook replicatie zeer makkelijk gemaakt

[EfBe]

cariolive23 schreef op woensdag 25 mei 2011 @ 18:00:
[...]
Mijn leven is 100x belangrijker dan welke database dan ook, maar toch rijd ik niet in de meest veilige auto. Waarom niet? Omdat ik daar het geld niet voor heb, ook niet wanneer de kosten blijkbaar bijzaak zijn.

Een project heeft een budget en wanneer dat al opgaat aan andere kosten, blijft er nul komma niks over voor de licentiekosten. Niks bijzonders en ook geen enkel probleem: Er zijn voldoende databases beschikbaar die standaard DBMS-functionaliteit in huis hebben.

Je snapt mijn punt niet. Wanneer je op zoek bent naar de beste database, dan is budget wellicht een factor, maar men moet niet overdrijven. TS heeft het over volledig herschrijven van een applicatie die kennelijk groter is dan een paar KB, m.a.w.: de kosten voor de programmeurs zijn een veelvoud van wat je bv voor Oracle zou moeten betalen. Dat het 'gratis' moet snap ik dan niet: beetje jammeren dat het anders geld kost, terwijl de programmeurs het veelvoud kosten. Dat neemt niet weg dat er goede gratis alternatieven zijn, maar deze thread duurt al 30+ posts en TS heeft nog steeds geen keuze kunnen maken. Volgens mij wordt het dan ook niet wat. Kennelijk zijn de gratis alternatieven (for the record, postgresql kan IMHO prima, jij ook weer blij ) niet voldoende, anders had TS de keuze al gemaakt.

En wat is "de beste DB die er is" ? Zoveel mensen, zoveel meningen. Komt bij dat er in dit topic maar een handvol requirements worden genoemd, daarmee wordt het lastig om "de beste DB" vast te stellen. PostgreSQL voldoet voor grote en kleine organistaties, is snel, uitstekende concurrency, goede documentatie, kost nul komma niks aan licentiekosten en draait op vrijwel ieder OS.

Ja daarom stelde ik dat ook voor. Je kunt ook naar Oracle kijken, kost wel geld maar weet je ook dat je goed zit. TS heeft dan alternatieven genoeg maar heeft toch twijfels:
- "de documentatie is niet goed", al gekeken?
- Postgresql is in TS' ogen kennelijk niet bij machte wat MySQL kan doen, anders had hij de keuze al gemaakt
- Commerciele databases zijn voor TS kennelijk not done want het mag geen cent kosten. Maar MySQL kost ook geld, en is het niet in licentie vorm dan is het wel in support vorm. En dat geeft niets, want het is een fractie van wat de programmeurs gaan kosten gedurende het project!

Penny wise, pound foolish.

Sorry, deze thread is gewoon bullshit. Mensen investeren tijd hier om advies te geven, maar TS is niet bij machte om een lijstje voor/nadelen op te stellen per alternatief en dan een keuze te maken en daar bij te blijven.

[Voor 9% gewijzigd door EfBe op 26-05-2011 09:02]

[kwaakvaak_v2]

Oracle + PHP != Best friends..

[0siris]

Nog even een speler op de markt gooien:
DB2

Resources:
DB2 Express-C may be run on any sized system with any amount of processors and memory, however DB2 Express-C will limit total resource utilization as follows:
* Processor: 2 cores
* Memory: 2 GB

't is in ieder geval multiplatform. Ik heb geen idee hoe groot je DB gaat zijn, misschien is 2 CPU cores en 2GB geheugenlimiet veel te klein...
Oracle heeft ook zo'n free version:

supporting up to 4GB of user data and running on a single processor, using a maximum of 1GB memory.

[Voor 20% gewijzigd door 0siris op 26-05-2011 09:06]

[Voutloos]

EfBe schreef op donderdag 26 mei 2011 @ 08:56:
Sorry, deze thread is gewoon bullshit. Mensen investeren tijd hier om advies te geven, maar TS is niet bij machte om een lijstje voor/nadelen op te stellen per alternatief en dan een keuze te maken en daar bij te blijven.

^^ Waarheid. Er zijn wel een paar goede vragen gesteld, maar vervolgens wordt er rustig in het wilde weg doorgekletst, en als je heel eerlijk bent deed je daar zelf aan mee.

Het wachten is gewoon op de ts, met meer eisen, details etc.

[jbdeiman]

EfBe schreef op donderdag 26 mei 2011 @ 08:56:
[...]

Je snapt mijn punt niet. Wanneer je op zoek bent naar de beste database, dan is budget wellicht een factor, maar men moet niet overdrijven. TS heeft het over volledig herschrijven van een applicatie die kennelijk groter is dan een paar KB, m.a.w.: de kosten voor de programmeurs zijn een veelvoud van wat je bv voor Oracle zou moeten betalen. Dat het 'gratis' moet snap ik dan niet: beetje jammeren dat het anders geld kost, terwijl de programmeurs het veelvoud kosten. Dat neemt niet weg dat er goede gratis alternatieven zijn, maar deze thread duurt al 30+ posts en TS heeft nog steeds geen keuze kunnen maken. Volgens mij wordt het dan ook niet wat. Kennelijk zijn de gratis alternatieven (for the record, postgresql kan IMHO prima, jij ook weer blij ) niet voldoende, anders had TS de keuze al gemaakt.


[...]

Ja daarom stelde ik dat ook voor. Je kunt ook naar Oracle kijken, kost wel geld maar weet je ook dat je goed zit. TS heeft dan alternatieven genoeg maar heeft toch twijfels:
- "de documentatie is niet goed", al gekeken?
- Postgresql is in TS' ogen kennelijk niet bij machte wat MySQL kan doen, anders had hij de keuze al gemaakt
- Commerciele databases zijn voor TS kennelijk not done want het mag geen cent kosten. Maar MySQL kost ook geld, en is het niet in licentie vorm dan is het wel in support vorm. En dat geeft niets, want het is een fractie van wat de programmeurs gaan kosten gedurende het project!

Penny wise, pound foolish.

Sorry, deze thread is gewoon bullshit. Mensen investeren tijd hier om advies te geven, maar TS is niet bij machte om een lijstje voor/nadelen op te stellen per alternatief en dan een keuze te maken en daar bij te blijven.

En jij snapt mijn punt niet, we hebben voor een aantal SQL varianten al een keuze gemaakt, en die worden het niet. Het gaat ook niet om ONZE kosten, maar omdat we voor instellingen met een beperkt ICT budget een applicatie maken willen we deze instellingen niet opzadelen met hogere kosten, wanneer ze intern willen draaien, ivm het aanschaffen van een licentie op een pakket aan extra benodigde software om met de applicatie te kunnen werken.
Je kan hoog en laag springen, zo is het beleid nu eenmaal en dat is een beleid wat door onze klantengroep ook enorm wordt gewaardeerd.

De keuze is al gemaakt (heb ik al eerder aangegeven, we gaan ook een proeftuin opzetten met PostgreSql), maar we gaan er wel voordat we het definitief maken gaan we er wel mee spelen en wat mee proberen. Het is wel iets waar we jaren mee door willen, dus dat het voor onszelf moet werken lijkt me geen rare eis.

kwaakvaak_v2 schreef op donderdag 26 mei 2011 @ 09:02:
Oracle + PHP != Best friends..

Mag ik vragen waarom, kan je bekende problemen aangeven of waar je zelf ervaring mee hebt?

0siris schreef op donderdag 26 mei 2011 @ 09:03:
Nog even een speler op de markt gooien:
DB2

[...]

't is in ieder geval multiplatform. Ik heb geen idee hoe groot je DB gaat zijn, misschien is 2 CPU cores en 2GB geheugenlimiet veel te klein...
Oracle heeft ook zo'n free version:

[...]

Het systeem wordt voor heel veel zaken gebruikt, denk aan het vastleggen van alle handelingen die worden gedaan, of alle producten die elke dag aan iemand worden geleverd. Dit keer 1600 cliënten (er zijn kleinere, maar ook grotere instellingen) en jaren lang, waarover men informatie op wil vragen.
De hoeveelheid data is enorm, en er worden zware en ingewikkelde query's uitgevoerd. Dit gebeurt ook verdeeld over meerdere gebruikers tegelijkertijd. Er zijn dus op momenten 10-tallen gebruikers die informatie opvragen, in de vorm van totalen/ overzichten, waarin dus ook berekeningen worden gedaan.

Oracle (Free) valt dan dus al af, het ondersteunen van meerdere cores is eigenlijk wel een must. Daarnaast moeten er meerdere gebruikers gelijkertijd mee kunnen werken, zonder dat ze last van elkaar hebben. (dat het iets trager wordt is begrijpelijk, in de huidige opzet is wanneer iemand een overzicht opvraagt, welke er lang over doet om op te bouwen vanuit een grote hoeveelheid data, iemand anders geen beschikking heeft over de data... => Table locking)

De geheugenlimiet van DB2 is ook wel aan de kleine kant, wellicht dat we (we gaan ook de structuur aanpassen) minder data op gaan slaan in de database dan nu, maar je moet er aan denken dat bij grote klanten +- 1 tot 1,5 gyg per jaar in 1 tabel erbij kan komen, wegens het (verplicht) bij houden van alle wijzigingen die zijn gedaan.

Voutloos schreef op donderdag 26 mei 2011 @ 09:41:
[...]
^^ Waarheid. Er zijn wel een paar goede vragen gesteld, maar vervolgens wordt er rustig in het wilde weg doorgekletst, en als je heel eerlijk bent deed je daar zelf aan mee.

Het wachten is gewoon op de ts, met meer eisen, details etc.

Ik snap dat het moeilijk is op basis van deze eisen een keuze te maken, ik zal eens opsommen wat belangrijk is, en proberen dit ook op volgorde te doen:

1. Betrouwbaarheid, zowel qua data-integriteit als qua bereikbaarheid
2. IVM data integriteit, ook mogelijkheid tot Foreign Keys
3. Snelheid, query's (ook ingewikkelde) moeten snel worden uitgevoerd
4. Master/ Slave (via SSL) constructie mogelijkheid (SSL niet verplicht, versleuteld wel!)
5. Hoge continuïteit, geen / nauwelijks snelheid verlies bij meerdere gebruikers
6. Gratis (niet voor ons, maar voor klanten die we IVM beperkt budget niet opzadelen met het verplicht afnemen van een licentie voor iets wat voor de applicatie benodigd is)
7. Multi (All?) platform. Komt voor(t) uit Gratis, de klant moet ongeacht wat voor OS er intern wordt gebruikt, ermee kunnen werken. (Servers draaien bij sommige klanten op Windows, bij anderen Linux)
8. Goede en duidelijke documentatie, we moeten onszelf het aan kunnen leren/ aan kunnen wennen. Bij vragen moet je zelf (snel/ eenvoudig) in de documentatie kunnen kijken/ zoeken.

Volgens mij zijn deze punten door het topic heen al naar voren gekomen, maar nu staan ze nog eens overzichtelijk bij elkaar.


Ps. Algemene noot:
Ik heb onderhand wel genoeg van het gedoe over het al dan niet kiezen voor een gratis pakket. De reden hiervoor is al meermalen duidelijk aangegeven en het is ook een punt wat niet gewijzigd gaat worden. Je hebt nu eenmaal te maken met een bepaalde markt.

[EfBe]

Het systeem wordt voor heel veel zaken gebruikt, denk aan het vastleggen van alle handelingen die worden gedaan, of alle producten die elke dag aan iemand worden geleverd. Dit keer 1600 cliënten (er zijn kleinere, maar ook grotere instellingen) en jaren lang, waarover men informatie op wil vragen.
De hoeveelheid data is enorm, en er worden zware en ingewikkelde query's uitgevoerd. Dit gebeurt ook verdeeld over meerdere gebruikers tegelijkertijd. Er zijn dus op momenten 10-tallen gebruikers die informatie opvragen, in de vorm van totalen/ overzichten, waarin dus ook berekeningen worden gedaan.

Dus de hardware kost ook meer dan een paar honderd euro. Mag ik vragen wat het pakket de klant kost? (dus met onderhoud etc. erbij) ? Omdat je niet eist dat het pakket op een specifiek OS draait, ga je wel opdraaien voor tweaking op het OS zelf. Een DB die goed draait op unix hoeft niet zo goed te draaien op windows en vice versa, daar ga je wel zelf voor opdraaien. Het is dan wellicht handiger en goedkoper om de hw + os zelf te leveren, je moet nl. toch beheer doen op de applicatie en dat kan beter op een os dat je kent + je hoeft minder kosten te maken om alles te testen op de meest uiteenlopende architecturen.

[Voor 11% gewijzigd door EfBe op 26-05-2011 11:41]

[jbdeiman]

EfBe schreef op donderdag 26 mei 2011 @ 11:40:
[...]

Dus de hardware kost ook meer dan een paar honderd euro. Mag ik vragen wat het pakket de klant kost? (dus met onderhoud etc. erbij) ? Omdat je niet eist dat het pakket op een specifiek OS draait, ga je wel opdraaien voor tweaking op het OS zelf. Een DB die goed draait op unix hoeft niet zo goed te draaien op windows en vice versa, daar ga je wel zelf voor opdraaien. Het is dan wellicht handiger en goedkoper om de hw + os zelf te leveren, je moet nl. toch beheer doen op de applicatie en dat kan beter op een os dat je kent + je hoeft minder kosten te maken om alles te testen op de meest uiteenlopende architecturen.

Die mogelijkheid bieden we ook, maar er zijn klanten die het prettiger vinden als ze niet over de internet verbinding bij het systeem zitten, maar intern op hun eigen server.
Het pakket kost de klant, afhankelijk van het aantal cliënten waarmee ze zaken doen, een behoorlijk bedrag. De precieze bedragen weet ik niet, ik ga hierom ook geen schatting neerzetten.

Wij gaan niet opdraaien voor Tweaking op het OS zelf, er wordt duidelijk aangegeven dat onze voorkeur is dat ze bij onze ASP gaan draaien, daar hebben we een Blade Server constructie, waardoor elke klant zijn/ haar eigen VPS kan krijgen. Hier draaien wij wel op voor de prestaties. Het blijft een keuze voor de klant, wij bieden de optie en het draaien op een VPS in ons beheer heeft zo zijn voordelen voor de klant, daar proberen we ook op aan te sturen, maar verplichten doen we het niet.
Met name ivm het werken met gevoelige persoonlijke data van mensen, zijn er klanten die niet willen dat dit over internet gebeurt.

[cariolive23]

Op wikipedia staat een overzicht van een groot aantal relationele databases. Hier vind je een flink aantal eigenschappen van deze databases en kun je dus een basisvergelijking mee maken. Maak vervolgens een shortlist van databases waar je meer over wilt weten en duik de handleidingen in om de details te leren kennen.

Dan jouw korte lijst met eisen:

Betrouwbaarheid, zowel qua data-integriteit als qua bereikbaarheid

Heel bijzonder dat je ooit voor MySQL hebt gekozen... Vrijwel iedere RDBMS heeft dit in huis, MySQL is hier de uitzondering op en heeft dit nog altijd slecht voor elkaar. Een standaard configuratie is in elk geval onbruikbaar.

IVM data integriteit, ook mogelijkheid tot Foreign Keys

Dit is standaard in iedere RDBMS, het is tenslotte een relationele database. MySQL is hier wederom de uitzondering, alleen de innoDB-engine kan dit.

Snelheid, query's (ook ingewikkelde) moeten snel worden uitgevoerd

Databases zoals DB2, Firebird, Oracle, PostgreSQL en SQL Server kunnen met zeer complexe queries nog uit de voeten en leveren allemaal een uitstekende performance. MySQL is nogmaals de uitzondering, kan eigenlijk alleen met eenvoudige queries goede performance leveren.

Ga het wel meten met jouw queries en jouw datamodel, dat is uiteindelijk het enige dat telt.

Master/ Slave (via SSL) constructie mogelijkheid (SSL niet verplicht, versleuteld wel!)

Een veilige verbinding kan ook via VPN, replicatie kennen de meeste databases wel. PostgreSQL heeft sinds versie 9.0 ingebouwde replicatie, met oudere versies kun je Slony gebruiken. MySQL heeft sinds versie 5.1 een goede replicatie in huis die ook nog eens eenvoudig is op te zetten en te beheren. Pluspuntje voor MySQL.

DB2, Oracle en SQL Server hebben allemaal uitstekende replicatie in huis, hier moet je wel aanvullende licenties voor afnemen. En die zijn niet goedkoop.

Hoge continuïteit, geen / nauwelijks snelheid verlies bij meerdere gebruikers

Vrijwel iedere database heeft prima voorzieningen voor concurrency, dat is net het hele idee achter een service: beschikbaar voor diverse gebruikers. MySQL is hier weer de uitzondering, het hangt af van de engine die je hebt gekozen en jouw toepassing of er wel of geen bruikbare concurrency is. Daarnaast schaalt MySQL niet al te best over meerdere processors en cores, zie de vele tests over dit onderwerp.

Gratis (niet voor ons, maar voor klanten die we IVM beperkt budget niet opzadelen met het verplicht afnemen van een licentie voor iets wat voor de applicatie benodigd is)

Wanneer je dit combineert met de eis van schaalbaarheid en replicatie, dan zijn alleen de open source databases een optie, DB2, Oracle en SQL Server zijn zeker niet gratis wanneer je meerdere cores, flink wat RAM en/of replicatie wilt gebruiken.

Multi (All?) platform. Komt voor(t) uit Gratis, de klant moet ongeacht wat voor OS er intern wordt gebruikt, ermee kunnen werken. (Servers draaien bij sommige klanten op Windows, bij anderen Linux)

SQL Server valt dan af, die eist Windows. Vrijwel alle andere databases draaien ook op Linux e.d.

Goede en duidelijke documentatie, we moeten onszelf het aan kunnen leren/ aan kunnen wennen. Bij vragen moet je zelf (snel/ eenvoudig) in de documentatie kunnen kijken/ zoeken.

Dat moet je zelf beoordelen, alleen jij kunt bepalen wat jij goed en duidelijk vindt. Ik zie de documentatie van PostgreSQL als een voorbeeld voor software documentatie, alles staat er in. Het is voor een beginner wellicht de kunst om jezelf te beperken tot een handvol hoofdstukken, de rest kun je dan later nog wel doen. Deze handleiding is ook in boekvorm te bestellen bij Bol.com

Succes!

[jbdeiman]

cariolive23 schreef op donderdag 26 mei 2011 @ 21:52:
Op wikipedia staat een overzicht van een groot aantal relationele databases. Hier vind je een flink aantal eigenschappen van deze databases en kun je dus een basisvergelijking mee maken. Maak vervolgens een shortlist van databases waar je meer over wilt weten en duik de handleidingen in om de details te leren kennen.

Dan jouw korte lijst met eisen:

[...]

Heel bijzonder dat je ooit voor MySQL hebt gekozen... Vrijwel iedere RDBMS heeft dit in huis, MySQL is hier de uitzondering op en heeft dit nog altijd slecht voor elkaar. Een standaard configuratie is in elk geval onbruikbaar.

Dat is een keuze geweest waar ik nooit bij betrokken ben, het systeem bestaat al een aantal jaren en er is steeds op doorontwikkeld. We lopen nu tegen de beperkingen van de huidige opzet aan, omdat ook grotere spelers in de markt interesse hebben in het pakket.
Die keuze is ooit gemaakt vanuit dat in het verleden begonnen is met MS Access om daar een applicatie in te maken, al snel werd het internet voor de applicatie een belangrijke speler, toen is voor MySQL gekozen, waarschijnlijk vanwege de beschikbaarheid en eenvoud ervan. Maar eenvoud in het maken blijkt maar weer geen garantie in eenvoud in onderhoud.

cariolive23 schreef op donderdag 26 mei 2011 @ 21:52:
[...]

Dit is standaard in iedere RDBMS, het is tenslotte een relationele database. MySQL is hier wederom de uitzondering, alleen de innoDB-engine kan dit.


[...]

Databases zoals DB2, Firebird, Oracle, PostgreSQL en SQL Server kunnen met zeer complexe queries nog uit de voeten en leveren allemaal een uitstekende performance. MySQL is nogmaals de uitzondering, kan eigenlijk alleen met eenvoudige queries goede performance leveren.

Ga het wel meten met jouw queries en jouw datamodel, dat is uiteindelijk het enige dat telt.


[...]

Een veilige verbinding kan ook via VPN, replicatie kennen de meeste databases wel. PostgreSQL heeft sinds versie 9.0 ingebouwde replicatie, met oudere versies kun je Slony gebruiken. MySQL heeft sinds versie 5.1 een goede replicatie in huis die ook nog eens eenvoudig is op te zetten en te beheren. Pluspuntje voor MySQL.

DB2, Oracle en SQL Server hebben allemaal uitstekende replicatie in huis, hier moet je wel aanvullende licenties voor afnemen. En die zijn niet goedkoop.


[...]

Vrijwel iedere database heeft prima voorzieningen voor concurrency, dat is net het hele idee achter een service: beschikbaar voor diverse gebruikers. MySQL is hier weer de uitzondering, het hangt af van de engine die je hebt gekozen en jouw toepassing of er wel of geen bruikbare concurrency is. Daarnaast schaalt MySQL niet al te best over meerdere processors en cores, zie de vele tests over dit onderwerp.


[...]

Wanneer je dit combineert met de eis van schaalbaarheid en replicatie, dan zijn alleen de open source databases een optie, DB2, Oracle en SQL Server zijn zeker niet gratis wanneer je meerdere cores, flink wat RAM en/of replicatie wilt gebruiken.


[...]

SQL Server valt dan af, die eist Windows. Vrijwel alle andere databases draaien ook op Linux e.d.


[...]

Dat moet je zelf beoordelen, alleen jij kunt bepalen wat jij goed en duidelijk vindt. Ik zie de documentatie van PostgreSQL als een voorbeeld voor software documentatie, alles staat er in. Het is voor een beginner wellicht de kunst om jezelf te beperken tot een handvol hoofdstukken, de rest kun je dan later nog wel doen. Deze handleiding is ook in boekvorm te bestellen bij Bol.com

Succes!

Voor de rest is PostgreSql eerste voorkeur, vandaag is een nieuwe collega begonnen, die er wel wat kennis van heeft al. Hij vind het ook een goede keuze. Voor ons omdat er ook in 1 klap al wat meer kennis is, is de keuze weer een stukje reëler geworden.

[kwaakvaak_v2]

Mag ik vragen waarom, kan je bekende problemen aangeven of waar je zelf ervaring mee hebt?

Mag je best vragen, maar het antwoord gaat toch niet van belang zijn in deze discussie, want oracle kost geld, en dat willen jullie niet door jullie klanten uit laten geven voor een DB laag.. En aangezien de keuze al gemaakt is voor postgresql is het motiveren waarom Oracle niet goed samenwerkt met PHP daarbij gelijk ook zonde van mijn tijd


Oh en cariolive zijn punten slaan hier en daar wel ergens op, ware het niet dat het leeuwedeel van zijn beweringen slaan op de myISAM engine, en elke zichzelf respecterende ontwikkelaar weet, dat je juist die engine moet vermijden als de pest, en gewoon voor innoDB moet kiezen.

[cariolive23]

kwaakvaak_v2 schreef op vrijdag 27 mei 2011 @ 11:58:
Oh en cariolive zijn punten slaan hier en daar wel ergens op, ware het niet dat het leeuwedeel van zijn beweringen slaan op de myISAM engine, en elke zichzelf respecterende ontwikkelaar weet, dat je juist die engine moet vermijden als de pest, en gewoon voor innoDB moet kiezen.

Helaas heeft een (te) groot deel van deze zichzelf respecterende ontwikkelaars nog nooit van SQL injection gehoord en hebben ze ook geen flauw idee hoe ze dit moeten voorkomen. De afgelopen weken zijn Sony en een reseller van Comodo SSL-certifcaten hier weer pijnlijk mee geconfronteerd.

En jij verwacht dat dit soort prutsers deze zichzelf respecterende ontwikkelaars wel weet wat MyISAM of innoDB is? Dat lijkt mij erg naief

[Voutloos]

Nu pak je random incidenten erbij (en Sony heeft op een groot aantal andere punten gefaald) voor een random punt.

Wat wel heel belangrijk is in deze: innoDB is eindelijk de default engine geworden in mysql 5.5 . Minstens vijf jaar te laat, maar het is dan toch gebeurd. Oftewel, nog even en de prutsers 'kiezen' vanzelf voor innoDB.

edit:
Absurde reactie hieronder, en ik heb er niet eens de kracht voor om op je random fails cq. sarcastische Oracle opmerkingen te reageren. Het ga je goed.

[Voor 19% gewijzigd door Voutloos op 27-05-2011 14:23]

[cariolive23]

Voutloos schreef op vrijdag 27 mei 2011 @ 13:29:
Nu pak je random incidenten erbij (en Sony heeft op een groot aantal andere punten gefaald) voor een random punt.

Random? Google eens op het nieuws van de afgelopen dagen over SQL injection, dan kom je nog véér meer dan dit soort "random" incidenten tegen. Joomla is er één van. Ik koos voor Sony en Comodo omdat dit grote namen zijn.

Wat wel heel belangrijk is in deze: innoDB is eindelijk de default engine geworden in mysql 5.5 . Minstens vijf jaar te laat, maar het is dan toch gebeurd. Oftewel, nog even en de prutsers 'kiezen' vanzelf voor innoDB.

Eindelijk! Gelukkig staat Monty niet meer aan het roer van MySQL en heeft Oracle dit overgenomen, anders waren de gebruikers van MySQL nog tot in lengte van dagen veroordeeld tot dit soort idiote instellingen.

Pas wel op met de vele SQL_mode's in MySQL, standaard is het nog steeds behelpen en gaat ook innoDB je niet beschermen tegen rare fouten in je SQL. Denk aan ongeldige GROUP BY's en het optellen van appels en peren: SELECT '1 appel' + ' en nog 2 peren';

[kwaakvaak_v2]

Dit wordt een wellus nietus, en mij postgres is beter dan jouw mysql discussie, en daar heb ik geen trek in. Ongeveer net zo nuttig als mijn ps3 is beter dan jouw x360 want......

Ik heb niks tegen postgresql, sterker nog.. Ik denk dat ik het binnenkort zelfs voor een project in ga zetten ipv de huidige perconaXTRADB waar het systeem nu op draait. Puur om wat meer hands on ervaring tussen doctrine2 en verschillende DB lagen te krijgen.

[EfBe]

cariolive23 schreef op vrijdag 27 mei 2011 @ 13:07:
[...]

Helaas heeft een (te) groot deel van deze zichzelf respecterende ontwikkelaars nog nooit van SQL injection gehoord en hebben ze ook geen flauw idee hoe ze dit moeten voorkomen. De afgelopen weken zijn Sony en een reseller van Comodo SSL-certifcaten hier weer pijnlijk mee geconfronteerd.

En jij verwacht dat dit soort prutsers deze zichzelf respecterende ontwikkelaars wel weet wat MyISAM of innoDB is? Dat lijkt mij erg naief

SQL injection heeft niets met data integrity te maken, waar je innoDB voor gebruikt. Een parameterized query op myIsam weerstaat sql injection net zo goed als innoDB dat doet: ze zitten na de SQL interpreter.

[jbdeiman]

EfBe schreef op zaterdag 28 mei 2011 @ 10:02:
[...]

SQL injection heeft niets met data integrity te maken, waar je innoDB voor gebruikt. Een parameterized query op myIsam weerstaat sql injection net zo goed als innoDB dat doet: ze zitten na de SQL interpreter.

Hier moet ik het helemaal mee eens zijn, InnoDB heeft zijn goede punten, maar heeft ook gewoon nadelen. Bedenk me net eigenlijk nog iets: Er wordt wel eens wat uit de database gehaald aan data, omdat dit niet meer aanpasbaar is/ mag zijn. Hiervan wordt een berekening gemaakt, de totalen worden opgeslagen in een andere tabel, waardoor we gegroepeerde data houden. De originele data wordt overgezet naar een andere database, maar is niet van belang voor de op te halen informatie. (we willen alleen wel deze data bewaren).

Nu is het in de InnoDB engine dat na het verwijderen van records deze gebruikte ruimte niet wordt vrijgegeven, maar feitelijk (net als Windows) wordt aangegeven dat het record niet meer bestaat, al wordt de ruimte die het ooit innam nog steeds ingenomen. Is dit in andere databases ook zo?


Overigens ga ik er nu vanuit dat het voor het nieuwe project minder van belang is, omdat we ws minder data gaan / hoeven te verwijderen (bijhouden van history is belangrijk).

[DiedX]

jbdeiman schreef op zaterdag 28 mei 2011 @ 11:24:
[...]


Nu is het in de InnoDB engine dat na het verwijderen van records deze gebruikte ruimte niet wordt vrijgegeven, maar feitelijk (net als Windows) wordt aangegeven dat het record niet meer bestaat, al wordt de ruimte die het ooit innam nog steeds ingenomen. Is dit in andere databases ook zo?

Volgens mij is dat in MySQL nog steeds zo (CORRECT ME IF I'M WRONG!!!)

PostgreSQL heeft vacuum, waarmee dat opgelost wordt.

[kwaakvaak_v2]

gevalletje RTFM : http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html

Komop zeg, op deze manier gaat je geloofwaardigheid heel snel richting het 0 punt.. Wel mee willen praten over oplossingen maar even de handleiding lezen is teveel werk voor de TS.

Ik ben nu echt weg uit deze discussie..

[jbdeiman]

kwaakvaak_v2 schreef op zaterdag 28 mei 2011 @ 13:32:
gevalletje RTFM : http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html

Komop zeg, op deze manier gaat je geloofwaardigheid heel snel richting het 0 punt.. Wel mee willen praten over oplossingen maar even de handleiding lezen is teveel werk voor de TS.

Ik ben nu echt weg uit deze discussie..

Prima, moet je zelf weten. Als je even reëel naar het topic kijkt dan is wel duidelijk dat ik wel degelijk naar voor/ nadelen heb gekeken, van alle in het topic genoemde databases de manual helemaal nazoeken op dit soort zaken gaat me wel wat ver. Ik moet toch zeggen dat ik de manier van reageren vaak heel kort door de bocht vind (algemene noot, niet alleen tov de gequote post, of tegen jou), ik stel denk ik helemaal geen gekke vraag, al krijg ik het idee dat een aantal het wel een gekke vraag vinden.

Het gaat mij erom dat ik dit noem, omdat het voor ons wel een voorwaarde kan zijn, maar dat we er nu vanuit gaan dat we niet zoveel uit de db weer weghalen. RTFM, is een leuke opmerking, zoals je kan zien in de verschillende posts die er zijn geweest, heb ik mijn voorwerk wel degelijk gedaan.

Opslagruimte is het kleinste van de issues waar we tegenaanlopen, omdat opslagruimte een behoorlijk goedkoop gemeengoed aan het worden is, of eigenlijk al is. Wel kan het op de "echt lange termijn" voordeel opleveren als dit beter gaat. MySQL staat ook niet 100% stil, het kan best zijn dat er iemand is die aan geeft, vanuit ervaring/ kennis dat het in MySQL ook goed mogelijk is om de InnoDB tabellen schoon/ compact te houden.

Maargoed, het is jou keuze als jij je niet kunt vinden in dit topic, dan moet je het maar laten.

[EfBe]

jbdeiman schreef op zaterdag 28 mei 2011 @ 11:24:
[...]
Hier moet ik het helemaal mee eens zijn, InnoDB heeft zijn goede punten, maar heeft ook gewoon nadelen.

Volgens mij noemde ik geen nadeel (noch een voordeel)

Bedenk me net eigenlijk nog iets: Er wordt wel eens wat uit de database gehaald aan data, omdat dit niet meer aanpasbaar is/ mag zijn. Hiervan wordt een berekening gemaakt, de totalen worden opgeslagen in een andere tabel, waardoor we gegroepeerde data houden. De originele data wordt overgezet naar een andere database, maar is niet van belang voor de op te halen informatie. (we willen alleen wel deze data bewaren).

Nu is het in de InnoDB engine dat na het verwijderen van records deze gebruikte ruimte niet wordt vrijgegeven, maar feitelijk (net als Windows) wordt aangegeven dat het record niet meer bestaat, al wordt de ruimte die het ooit innam nog steeds ingenomen. Is dit in andere databases ook zo?

Je kunt die wel terugclaimen maar het is eigenlijk nadelig. Een RDBMS gebruikt een database file als een virtuele disk, met een eigen 'bestandssysteem' (pages). Data die uit de database verdwijnt zal ervoor zorgen dat pages worden verwijderd en dat er gaten ontstaan. Echter een goed RDBMS kan goed daarmee omgaan en heeft geen last van dergelijke gaten. Wat nadelig is is wanneer je deze files gaat opschonen, dus dat de files net zo groot op de feitelijke disk worden als er page data in zit. Wanneer je dan nieuwe data in een tabel stopt, moet er een page bij en moet de file op disk groter gemaakt worden wat fragmentatie oplevert: dit wil je niet, want dit is op den duur erg vertragend. Dus laten RDBMS-en de file lekker zoals hij is, en hoeft bij nieuwe data geen re-allocatie plaats te vinden.

Men denkt wel eens dat het herpakken van de pages performance winst oplevert, maar dit is niet zo: op den duur levert dit problemen op bij table / index scans, want wanneer je alle pages packt en dan data insert komt dat op een page terecht die achter de al bestaande pages is geplaatst, wat een harddisk kop step oplevert. Wat je wilt in een ideale situatie is dat alle pages in een beweging van de harddisk kop kunnen worden gelezen. Het hangt van de volatiliteit van de data af wat je moet doen, maar feitelijk zou ik hier niet naar kijken. (mits je een database neemt die dit zelf goed regelt)

Overigens ga ik er nu vanuit dat het voor het nieuwe project minder van belang is, omdat we ws minder data gaan / hoeven te verwijderen (bijhouden van history is belangrijk).

Je hebt 2 files per database: de data en de transaction log. (soms ook extra database files voor blobs, mocht je database dat ondersteunen, dus dat je blob data buiten de feitelijke table data opslaat). De database file blijf je af, en de transaction log truncate je bij backups. Zodoende kun je de transaction log beheersbaar houden en toch transactions replayen. Geen idee of MySQL dat kan, het zou me niets verbazen als dat niet het geval was (maar het zou kunnen)

[Sfynx]

Wat een gedoe zeg om in PostgreSQL even een gebruiker alleen SELECT toegang te geven op een complete database (read only access dus). Dat is blijkbaar gewoon niet mogelijk op een nette manier terwijl je bij MySQL gewoon een GRANTje doet en klaar.
Op alle tabellen die permissie zetten en dan later er weer om moeten denken als er een tabel bijgekomen is vind ik geen nette oplossing. Het zal mijn gebrek aan ervaring met PostgreSQL wel zijn, maar het permissiesysteem van MySQL voelt persoonlijk iets logischer en toegankelijker aan.

[Voor 6% gewijzigd door Sfynx op 03-06-2011 02:09]

[Wolfboy]

Sfynx schreef op vrijdag 03 juni 2011 @ 02:07:
Wat een gedoe zeg om in PostgreSQL even een gebruiker alleen SELECT toegang te geven op een complete database (read only access dus). Dat is blijkbaar gewoon niet mogelijk op een nette manier terwijl je bij MySQL gewoon een GRANTje doet en klaar.
Op alle tabellen die permissie zetten en dan later er weer om moeten denken als er een tabel bijgekomen is vind ik geen nette oplossing. Het permissiesysteem van MySQL voelt persoonlijk iets logischer en toegankelijker aan.

Bij versie 9 en hoger kan je default rechten voor een database instellen zodat je die problemen niet hebt.

Het permissiesysteem van Postgres is erg uitgebreid, maar soms niet heel prettig in het gebruik nee. Al is het meestal gewoon een kwestie van wat gebruikersgroepen aanmaken en je bent zo klaar

[cariolive23]

Sfynx schreef op vrijdag 03 juni 2011 @ 02:07:
Wat een gedoe zeg om in PostgreSQL even een gebruiker alleen SELECT toegang te geven op een complete database (read only access dus).

Sinds wanneer krijgt een gebruiker "even" rechten? Klinkt als een uitzondering en dat is vaak het begin van veiligheidsproblemen. Heeft trouwens niets met het merk database te maken.

Dat is blijkbaar gewoon niet mogelijk op een nette manier terwijl je bij MySQL gewoon een GRANTje doet en klaar.

GRANT werkt uitstekend in PostgreSQL en een default setting is ook gewoon mogelijk.

Op alle tabellen die permissie zetten en dan later er weer om moeten denken als er een tabel bijgekomen is vind ik geen nette oplossing.

Jij misschien niet, de verantwoordelijke mensen voor de beveiliging hebben daar een andere mening over. Liever een tabelletje te weinig open gezet, dan een lek in de beveiliging.

Het zal mijn gebrek aan ervaring met PostgreSQL wel zijn, maar het permissiesysteem van MySQL voelt persoonlijk iets logischer en toegankelijker aan.

PostgreSQL wordt gezien als één van de meest veilige databases, dat heeft zijn prijs.

Wanneer je echter vooraf de groepen goed gaat inrichten, hoef je alleen deze groepen te onderhouden en kun je daar "even" een gebruiker aan hangen wanneer deze "even" wat rechten nodig heeft. Wanneer jij dus een groep "read_only" hebt gemaakt, heb je met één simpel opdrachtje een nieuwe rol hieraan toegevoegd:

SQL:

CREATE ROLE "Sfynx" WITH LOGIN PASSWORD 'geheim' IN ROLE read_only;

De rol "Sfynx" is nu aangemaakt en krijgt in één keer alle rechten van de rol "read_only". Iedere wijziging voor "read_only" zal ook direct van toepassing zijn op alle leden van deze groep, dus ook voor "Sfynx".

Het beheer van rechten en rollen is niet moeilijk, je moet het alleen even eenvoudig inrichten voor jezelf: Eerst groepen aanmaken (rollen die niet kunnen inloggen) en dan pas rollen aan deze groepen hangen die wél kunnen inloggen.

[jbdeiman]

kwaakvaak_v2 schreef op vrijdag 27 mei 2011 @ 11:58:
[...]


Mag je best vragen, maar het antwoord gaat toch niet van belang zijn in deze discussie, want oracle kost geld, en dat willen jullie niet door jullie klanten uit laten geven voor een DB laag.. En aangezien de keuze al gemaakt is voor postgresql is het motiveren waarom Oracle niet goed samenwerkt met PHP daarbij gelijk ook zonde van mijn tijd


Oh en cariolive zijn punten slaan hier en daar wel ergens op, ware het niet dat het leeuwedeel van zijn beweringen slaan op de myISAM engine, en elke zichzelf respecterende ontwikkelaar weet, dat je juist die engine moet vermijden als de pest, en gewoon voor innoDB moet kiezen.

Dat dit voor mij niet van belang is, wil niet zeggen dat het loze informatie is. Ik weet dat hier vaak wordt verwezen naar topics met (deels) een zelfde onderwerp/ vraagstelling. Ik merk dat het topic redelijk wat stof heeft doen opwaaien, met name MySQL heeft het zwaar te verduren al is niet alles wat daar over gezegd is nog van toepassing wanneer je de instellingen goed hebt staan.

Die punten voor het inserten en dergelijke zijn (Gevonden) benchmarks op internet, hoe en wat weet ik niet, wel weet ik dat daarbij aan was gegeven dat beide databases dezelfde opzet hadden, dus indien met foreign keys is gewerkt, werd dat op beide plekken gedaan.

[Anoniem: 384971]

Laat ik eens raar doen en een situatieschets maken. Let wel, dit is mijn persoonlijke mening en ik merk het dus uitdrukkelijk niet aan als feit.

MySQL "voelt aan" als een hobbyproject, zowel in vergelijking met PostgreSQL als in de structuur van een front-end die dingetjes doet om te proberen net te doen of er geen verschil zit tussen de verschillende database engines maar die zijn er wel degelijk. D'een doet snel en d'ander doet dataintegriteit, d'n derde is gejat van PostgreSQL, en zo verder.

PostgreSQL is in vergelijking een "echte" database, met een focus om deze ene engine alles te laten doen en daarbij vast te houden aan eisen als dataintegriteit.

MySQL zie je op veel plekken opduiken; zag laatst dat een kde of wat was het installatie op je desktop je er een MySQL installatie bijgaf een beetje zoals firefox een sqlite meezuigt. Het is een hele populaire keuze voor webserverscripting, maar niet omdat daar nu zulke intelligente SQL queries gemaakt worden. Wil je doen "wat iedereen doet" dan zal een MySQL je best van dienst kunnen zijn. Ik bedoel, het zal net zo prima werken als overal elders.

Wil je meer keuze? Je kan eens kijken of firebird alles doet wat je wil maar --ik heb het zelf nog niet gebruikt-- als ik zo rondkijk lijkt het nog wat te mogen afbakken daar cmdline en docs een beetje op PostgreSQL achterlopen, hoewel het wel meer "echte" SQL database is dan MySQL.

Wil je ook werkelijk capriolen uithalen met SQL dan zou ik eerst eens goed kijken of PostgreSQL alles kan wat ik nodig heb. Scheelt een hoop "oh nee dit kan alleen in die andere engine, en die gebruiken we niet want...". Qua "snelle engine" heb ik gemerkt dat eens goed naar tabel- en querygebruik kijken en een indexje hier of daar er bij makkelijk meer uitmaakt. Als je database de bottleneck lijkt dan doe je waarschijnlijk iets niet goed.

Dus, zo kijk ik er tegenaan: Populair, MySQL. Database, PostgreSQL.

[HMS]

Ik weet niet of het al genoemd is, maar moet er geen licentie genomen worden op MySQL voor commercial use?

[Voutloos]

Niet genoemd, want dat is niet nodig.

[Wolfboy]

Voutloos schreef op dinsdag 07 juni 2011 @ 12:11:
Niet genoemd, want dat is niet nodig.

Niet geheel waar. De MySQL client library gebruikt de GPL licentie dus als je die wil integereren dan ben je verplicht de broncode van de client ook vrij te geven.

Als je het als losse module meelevert is het natuurlijk geen probleem overigens.

[kwaakvaak_v2]

Wolfboy schreef op dinsdag 07 juni 2011 @ 13:01:
[...]
Niet geheel waar. De MySQL client library gebruikt de GPL licentie dus als je die wil integereren dan ben je verplicht de broncode van de client ook vrij te geven.

Als je het als losse module meelevert is het natuurlijk geen probleem overigens.

Dus in het geval van een PHP applicatie is dat niet nodig, omdat de client voor mySQL in PHP zit, en niet in je applicatie. (mySQL client != je eigen query abstractie class uiteraard)