Hey allemaal,
wat is nou eigenlijk het verschil tussen MySQL en PostgreSQL?
grtz
7 views
In het kort komt het neer op data-integriteit.
MySQL doet vrijwel niets om er voor te zorgen dat jouw data niet corrupt raakt (lijkt mij de kern van een databse...). Tevens zit er nauwelijks verband tussen de diverse tabellen, wanneer je de myIsam-engine gebruikt, foreign-keys worden niet eens ondersteund. Net zoals transacties en nog vele andere zaken.
PostgreSQL is een volledige relationele database die je gewoon kunt vergelijken met zwaargewichten als Oracle en DB2. MySQL kan, en mag, nog niet eens in de schaduw staan...
Op www.yapf.net staat een mooi overzicht van alle zwakke punten van MySQL, maar helaas is de site al een paar dagen offline. Er zijn vast wel andere sites met soortgelijke vergelijkingen.
MySQL doet vrijwel niets om er voor te zorgen dat jouw data niet corrupt raakt (lijkt mij de kern van een databse...). Tevens zit er nauwelijks verband tussen de diverse tabellen, wanneer je de myIsam-engine gebruikt, foreign-keys worden niet eens ondersteund. Net zoals transacties en nog vele andere zaken.
PostgreSQL is een volledige relationele database die je gewoon kunt vergelijken met zwaargewichten als Oracle en DB2. MySQL kan, en mag, nog niet eens in de schaduw staan...
Op www.yapf.net staat een mooi overzicht van alle zwakke punten van MySQL, maar helaas is de site al een paar dagen offline. Er zijn vast wel andere sites met soortgelijke vergelijkingen.
Nouja, dat is waar, maar enkel op data technisch gebied, de relaties. De tradeoff die mysql zo populair maakt is dat het doordat deze er niet standaard in zitten mysql razend snel is (dwz veel sneller) en voor zwaarbeladen servers, en webservers bijvoorbeeld veel interessanter is.
Veel webapplicaties hebben niet de foreign key methodiek nodig, laat staan transacties, waar deze voor bedrijven met enorme klanten databases van veel groter belang is dat de integriteit bewaakt wordt.
Door die functionaliteit te strippen is mysql zeer geschikt voor grote hoeveelheden SELECT commands.
Veel webapplicaties hebben niet de foreign key methodiek nodig, laat staan transacties, waar deze voor bedrijven met enorme klanten databases van veel groter belang is dat de integriteit bewaakt wordt.
Door die functionaliteit te strippen is mysql zeer geschikt voor grote hoeveelheden SELECT commands.
@Arend: In een relationele database kun je niet zonder foreignkeys werken. Doe je dat wel, dan neem je bewust het risico op corrupte data. Ook als klein bedrijf met een klein klantenbestand wil ik beschikken over betrouwbare gegevens. Waarom zou je dat niet willen? Omdat jouw hostingprovider geen PostgreSQL aanbiedt? Zoek dan een betere, die zijn zeker te vinden en dat hoeft echt niet meer geld te kosten. PostgreSQL is tenslotte ook opensource en gratis te downloaden, installeren en gebruiken.
En wat die zware belasting betreft, met MySQL heb je in complexe situaties veel meer queries (en dus verbindingen) nodig dan in PostgreSQL. PostgreSQL kan dus met minder verbindingen net zo veel, of zelfs meer, data verwerken dan MySQL. Ga je maar eens verdiepen in SCHEMA, dan gaat er een wereld voor je open.
Verder staan er op tweakers.net 2 artikelen over servers waarbij men MySQL en PostgreSQL heeft vergeleken. In beide gevallen kwam PostgreSQL als overduidelijke winnaar uit de bus. Zie http://tweakers.net/reviews/637 en http://tweakers.net/reviews/633 Komt nog eens bij dat men de PostgreSQL-database nog niet eens had geoptimaliseerd, het verschil had dus nog groter kunnen zijn.
MySQL is eigenlijk gewoon af te raden, zeker versies ouder dan versie 5. En dan heb ik het ook nog over versie 5 in strict-mode, anders heb je nog geen donder aan de extra's...
En wat die zware belasting betreft, met MySQL heb je in complexe situaties veel meer queries (en dus verbindingen) nodig dan in PostgreSQL. PostgreSQL kan dus met minder verbindingen net zo veel, of zelfs meer, data verwerken dan MySQL. Ga je maar eens verdiepen in SCHEMA, dan gaat er een wereld voor je open.
Verder staan er op tweakers.net 2 artikelen over servers waarbij men MySQL en PostgreSQL heeft vergeleken. In beide gevallen kwam PostgreSQL als overduidelijke winnaar uit de bus. Zie http://tweakers.net/reviews/637 en http://tweakers.net/reviews/633 Komt nog eens bij dat men de PostgreSQL-database nog niet eens had geoptimaliseerd, het verschil had dus nog groter kunnen zijn.
MySQL is eigenlijk gewoon af te raden, zeker versies ouder dan versie 5. En dan heb ik het ook nog over versie 5 in strict-mode, anders heb je nog geen donder aan de extra's...
Natuurlijk is het zo dat integriteit vanuit de database gewenst is in bepaalde applicaties. Wanneer dit zo is, is mysql waardeloos. Maar daarbuiten is mysql natuurlijk verre van waardeloos.
Ik wist niet dat je een postgresql-fanboy was, en ik wilde verre van in een mysql vs postgresql debat verzeild raken. Ik wilde enkel de raison d' etre van mysql uitleggen aan de OT, die vroeg om het verschil.
Ik probeer uitleggen dat mysql een minder complete database is, waarbij door niet de complete ANSI standaard voor SQL te implementeren tijdswinst wordt geboekt op het gebied van vele queries. Kortom: PostgreSQL is een completere database, en mysql een 'gehackte' versie die op bepaalde punten meer performance scoort.
Of je de tradeoff aan compatibiliteit en minder rationele integriteit acceptabel vind, is natuurlijk aan de programmeur. Als jij dat in geen geval acceptabel vind is dat een mening, en geen feit.
Daarom vind ik de stellingen dat MySQL waardeloos is wat dom en ongenuanceerd. Tweakers heeft niet mysql en postgresql vergeleken, maar moederborden. De SQL tests worden niet verder toegelicht, en gaan over het aantal threads dat gebruikt wordt, niet over de performance, of de typen selects. (Zoals ik zei: MySQL kan bepaalde requests sneller afhandelen, vandaar de populariteit onder webdevvers).
Ik wist niet dat je een postgresql-fanboy was, en ik wilde verre van in een mysql vs postgresql debat verzeild raken. Ik wilde enkel de raison d' etre van mysql uitleggen aan de OT, die vroeg om het verschil.
Ik probeer uitleggen dat mysql een minder complete database is, waarbij door niet de complete ANSI standaard voor SQL te implementeren tijdswinst wordt geboekt op het gebied van vele queries. Kortom: PostgreSQL is een completere database, en mysql een 'gehackte' versie die op bepaalde punten meer performance scoort.
Of je de tradeoff aan compatibiliteit en minder rationele integriteit acceptabel vind, is natuurlijk aan de programmeur. Als jij dat in geen geval acceptabel vind is dat een mening, en geen feit.
Daarom vind ik de stellingen dat MySQL waardeloos is wat dom en ongenuanceerd. Tweakers heeft niet mysql en postgresql vergeleken, maar moederborden. De SQL tests worden niet verder toegelicht, en gaan over het aantal threads dat gebruikt wordt, niet over de performance, of de typen selects. (Zoals ik zei: MySQL kan bepaalde requests sneller afhandelen, vandaar de populariteit onder webdevvers).
@Arend: Ik ben geen fanboy, van wat voor database dan ook, daarvoor ben ik te zakelijk. Het is wel zo dat ik nooit MyIsam-tabellen gebruik in MySQL maar altijd innoDB. Puur en alleen voor de data-integriteit.
Sinds kort heb ik een Postgre- / PHP-programmeur in dienst. En wat die jongen mij iedere week weer voorschotelt, daar valt mij de bek van open. Wat ik eerder allemaal in PHP zat te programmeren, stopt hij allemaal in de database. Volledige controle-structuren e.d. komen nu in de database en worden niet meer in PHP geprogrammeerd. Hierdoor zijn er vanuit de webserver, waar de PHP wordt geparsed, ook veel minder connecties met de database nodig (ik schat een factor 5 tot 10). MySQL kan dan misschien wel veel sneller requests afhandelen, maar de PostgreSQL-database, die wij nu aan het bouwen zijn, heeft veel minder requests nodig. Voor de uiteindelijke snelheid van de website maakt het dus niet uit. Komt nog eens bij dat ik liever een langzamere maar veilige database heb, dan een snellere die nauwelijks garanties geeft op de data-integriteit.
Stop maar eens een string van 10 karakters in een CHAR(8). Geen enkel probleem in MySQL, alleen jammer dat je de laatste 2 karakters kwijt raakt... Vanaf MySQL 5 heeft men dit opgelost, maar uitsluitend wanneer je in strict-mode werkt. Daarvoor ben je afhankelijk van de dba.
En wat betreft mijn corrupte-database-fobie, dat heeft waarschijnlijk te maken met mijn ervaring met databases van banken en verzekeraars en beveiliging in zijn algemeenheid. Beveiliging en data-integriteit gaan voor alles en moeten met hand en tand worden verdedigd. De DBA's ontvangen daarvoor ook een riant salaris, maar dat zijn ze zeker waard.
Sinds kort heb ik een Postgre- / PHP-programmeur in dienst. En wat die jongen mij iedere week weer voorschotelt, daar valt mij de bek van open. Wat ik eerder allemaal in PHP zat te programmeren, stopt hij allemaal in de database. Volledige controle-structuren e.d. komen nu in de database en worden niet meer in PHP geprogrammeerd. Hierdoor zijn er vanuit de webserver, waar de PHP wordt geparsed, ook veel minder connecties met de database nodig (ik schat een factor 5 tot 10). MySQL kan dan misschien wel veel sneller requests afhandelen, maar de PostgreSQL-database, die wij nu aan het bouwen zijn, heeft veel minder requests nodig. Voor de uiteindelijke snelheid van de website maakt het dus niet uit. Komt nog eens bij dat ik liever een langzamere maar veilige database heb, dan een snellere die nauwelijks garanties geeft op de data-integriteit.
Stop maar eens een string van 10 karakters in een CHAR(8). Geen enkel probleem in MySQL, alleen jammer dat je de laatste 2 karakters kwijt raakt... Vanaf MySQL 5 heeft men dit opgelost, maar uitsluitend wanneer je in strict-mode werkt. Daarvoor ben je afhankelijk van de dba.
En wat betreft mijn corrupte-database-fobie, dat heeft waarschijnlijk te maken met mijn ervaring met databases van banken en verzekeraars en beveiliging in zijn algemeenheid. Beveiliging en data-integriteit gaan voor alles en moeten met hand en tand worden verdedigd. De DBA's ontvangen daarvoor ook een riant salaris, maar dat zijn ze zeker waard.
het kmot er dus op neer dat Postgre een veel uitgebreiderde (spelling? lol) database is?
Zoals een soort 'script' dat je erin kan verwerken? het dus bv mogelijk te maken om de database niet meer als een 'bestand met informatie' te maken?
Zoals een soort 'script' dat je erin kan verwerken? het dus bv mogelijk te maken om de database niet meer als een 'bestand met informatie' te maken?
@Frank: Over controlestructuren in de databank ben ik het totaal niet met je eens.
Een databank moet je zo min mogelijk belasten vind ik. De conrolestructoren horen in PHP vind ik. Je schrijft dan wel iets meer PHP, maar de databank 'presteert beter'.
Ook zou je voor het gebruiksvriendelijke én het minder belasten van zowel de webserver als de databankserver ook controlestructuren in Javascript moeten inbouwen, en die ervoor zorgen dat een formulier met inhoud dat in de databank moet komen niet foutief aan kán (mits Javascript niet aanwezig is of uitgeschakeld staat) komen bij een PHP-script dat de inhoud nog eens gaat controleren en mischien in de databank gaat stoppen.
Zou je eens aan die jongen kunnen vragen waarom hij controlestructuren in de databank inbouwd? Ik ben zeer benieuwd daarnaar. :c)
Een databank moet je zo min mogelijk belasten vind ik. De conrolestructoren horen in PHP vind ik. Je schrijft dan wel iets meer PHP, maar de databank 'presteert beter'.
Ook zou je voor het gebruiksvriendelijke én het minder belasten van zowel de webserver als de databankserver ook controlestructuren in Javascript moeten inbouwen, en die ervoor zorgen dat een formulier met inhoud dat in de databank moet komen niet foutief aan kán (mits Javascript niet aanwezig is of uitgeschakeld staat) komen bij een PHP-script dat de inhoud nog eens gaat controleren en mischien in de databank gaat stoppen.
Zou je eens aan die jongen kunnen vragen waarom hij controlestructuren in de databank inbouwd? Ik ben zeer benieuwd daarnaar. :c)
@Jip: Dat hoef ik hem niet te vragen, dat weet ik zelf gelukkig wel. Stel dat jouw database door meerdere systemen wordt gebruikt en in 1 systeem zit een bug. Die kan dan de hele database onderuit halen en corrupt maken.
In de database draait het om de data, het beschermen en beschikbaar stellen daarvan. Bij het bouwen van de database bepaal je hoe je een telefoonnummer gaat opslaan, bv. 10 cijfers zonder verder enige opmaak. Vervolgens ga je bepalen welke telefoonnummers geldig zijn (voorkomen van corrupte data), dat doe je dan ook in de database en dus niet in PHP, Java, .Net of wat dan ook. Uiteraard mag je het daar ook al controleren, wordt vaak gedaan, maar het is uiteindelijk de database die bepaald of de data correct is of niet. Dus hoe brak de overige systemen ook zijn, als de database goed is, zul je nooit en te nimmer problemen krijgen met de data. En dat is precies de bedoeling.
Nu kun je roepen dat de database het zwakke punt is, maar dat is slechts 1 punt. Wanneer je 3 verschillende systemen hebt die gebruik maken van de database, heb je 3 zwakke punten. Dat lijkt mij een ongewenste situatie.
Voor meer informatie zou je echt eens met een Oracle- of DB2-dba moeten gaan praten, dan gaat er een wereld voor je open.
En een database kan echt wel een paar gebruikers gelijktijdig afhandelen, dat is niet het eerste waar jij je druk over hoeft te maken. Een database is er om zwaar belast te worden, anders kun je de boel ook wel in platte tekst wegschrijven...
In de database draait het om de data, het beschermen en beschikbaar stellen daarvan. Bij het bouwen van de database bepaal je hoe je een telefoonnummer gaat opslaan, bv. 10 cijfers zonder verder enige opmaak. Vervolgens ga je bepalen welke telefoonnummers geldig zijn (voorkomen van corrupte data), dat doe je dan ook in de database en dus niet in PHP, Java, .Net of wat dan ook. Uiteraard mag je het daar ook al controleren, wordt vaak gedaan, maar het is uiteindelijk de database die bepaald of de data correct is of niet. Dus hoe brak de overige systemen ook zijn, als de database goed is, zul je nooit en te nimmer problemen krijgen met de data. En dat is precies de bedoeling.
Nu kun je roepen dat de database het zwakke punt is, maar dat is slechts 1 punt. Wanneer je 3 verschillende systemen hebt die gebruik maken van de database, heb je 3 zwakke punten. Dat lijkt mij een ongewenste situatie.
Voor meer informatie zou je echt eens met een Oracle- of DB2-dba moeten gaan praten, dan gaat er een wereld voor je open.
En een database kan echt wel een paar gebruikers gelijktijdig afhandelen, dat is niet het eerste waar jij je druk over hoeft te maken. Een database is er om zwaar belast te worden, anders kun je de boel ook wel in platte tekst wegschrijven...
Ik snap je punt. Maar toch zou ik via PHP al bepalen of de data juist of foutief is. Het scheelt de databankserver minder werk omdat hij geen foutmelding terug hoeft te geven, het is voor de script- of programmeertaal ietsje meer werk, maar dat mag geen naam hebben en de gebruiker profiteerd er nadien óók van, omdat hij door Javascript al op de hoogte is gesteld van een foutief formulier en dat nog voor het verzenden kan wijzigen.
Ook als er geen Javascript aanwezig is is het voor de gebruiker sneller, door het wegvallen van de databankconnectie.
Volgens mij ben ik niet helemaal duidelijk genoeg geweest.
Zoals ik tot nu toe gelezen hebt, weigert PostgreSQL een record toe te voegen van 10 tekens in een veld waar maar 5 tekens toegestaan zijn.
Dus waarom zou je in je PHP-applicatie niet een extra controlestructuur aanbrengen die eventjes controleert of die tekst niet langer dan 5 tekens is. Er hoeft dan niet eens een verbinding te komen.
Stel dat die controlestructuur niet in een andere applicatie aanwezig is die met dezelfde databank werkt, krijgt die altijd nog een foutmelding van PostgreSQL terug, waardoor data dus niet corrupt kan worden.
Of zie ik dat nou verkeerd?
Edit: Typo :c)
Ook als er geen Javascript aanwezig is is het voor de gebruiker sneller, door het wegvallen van de databankconnectie.
(. . .)
Stel dat jouw database door meerdere systemen wordt gebruikt en in 1 systeem zit een bug. Die kan dan de hele database onderuit halen en corrupt maken.
(. . .)
Volgens mij ben ik niet helemaal duidelijk genoeg geweest.
Zoals ik tot nu toe gelezen hebt, weigert PostgreSQL een record toe te voegen van 10 tekens in een veld waar maar 5 tekens toegestaan zijn.
Dus waarom zou je in je PHP-applicatie niet een extra controlestructuur aanbrengen die eventjes controleert of die tekst niet langer dan 5 tekens is. Er hoeft dan niet eens een verbinding te komen.
Stel dat die controlestructuur niet in een andere applicatie aanwezig is die met dezelfde databank werkt, krijgt die altijd nog een foutmelding van PostgreSQL terug, waardoor data dus niet corrupt kan worden.
Of zie ik dat nou verkeerd?
Edit: Typo :c)
Javascript heeft eigenlijk helemaal niets met controles te maken, dat is alleen leuk om de boel wat gebruikersvriendelijker te maken. Een foutmelding tijdens het invoeren en niet achteraf. Verder heb je er niets aan.
Natuurlijk maak je in je php-code de controles op de data. Maar wanneer je honderden gegevens moet controleren, bestaat er een kans dat je ergens een fout maakt. Of eigenlijk heb je wel de garantie dat je ergens een fout maakt. Ook bij het testen komen deze fouten niet altijd aan het licht. Daarom zorg je er voor dat alle data binnen de database wordt gevalideerd. Wanneer er dan een onjuiste data naar de database wordt gestuurd, wordt dit keurig afgekeurd en krijg je van de database een fraaie foutmelding retour.
En helemaal juist, wanneer een ander systeem helemaal niets controleert, krijgt deze het toch niet voor elkaar om onjuiste data in de database weg te schrijven. Dit omdat de database dit zelf controleert. Het is dus veiliger.
En mocht blijken dat er een fout in de database zit, dan hoef je deze fout alleen maar in de database te verhelpen.
Wat je tegenwoordig ziet, is het valideren van gegevens m.b.v. XML-schema. Er wordt 1 schema beschikbaar gesteld, waar vervolgens ieder systeem, behalve de database..., gebruik van maakt. Op die manier kun je binnen een bedrijf vrij eenvoudig data eenduidig gaan valideren. Een telefoonnummer wordt dan door ieder systeem op dezelfde manier gecontroleerd, er is tenslotte maar 1 xml-schema om dit te controleren. Vindt er dan een wijziging plaats (bv. 12 nummers i.p.v. 10) dan hoef je dit maar op 1 plaats (+ de database) aan te passen en niet in ieder systeem apart.
Natuurlijk maak je in je php-code de controles op de data. Maar wanneer je honderden gegevens moet controleren, bestaat er een kans dat je ergens een fout maakt. Of eigenlijk heb je wel de garantie dat je ergens een fout maakt. Ook bij het testen komen deze fouten niet altijd aan het licht. Daarom zorg je er voor dat alle data binnen de database wordt gevalideerd. Wanneer er dan een onjuiste data naar de database wordt gestuurd, wordt dit keurig afgekeurd en krijg je van de database een fraaie foutmelding retour.
En helemaal juist, wanneer een ander systeem helemaal niets controleert, krijgt deze het toch niet voor elkaar om onjuiste data in de database weg te schrijven. Dit omdat de database dit zelf controleert. Het is dus veiliger.
En mocht blijken dat er een fout in de database zit, dan hoef je deze fout alleen maar in de database te verhelpen.
Wat je tegenwoordig ziet, is het valideren van gegevens m.b.v. XML-schema. Er wordt 1 schema beschikbaar gesteld, waar vervolgens ieder systeem, behalve de database..., gebruik van maakt. Op die manier kun je binnen een bedrijf vrij eenvoudig data eenduidig gaan valideren. Een telefoonnummer wordt dan door ieder systeem op dezelfde manier gecontroleerd, er is tenslotte maar 1 xml-schema om dit te controleren. Vindt er dan een wijziging plaats (bv. 12 nummers i.p.v. 10) dan hoef je dit maar op 1 plaats (+ de database) aan te passen en niet in ieder systeem apart.