Postgres VS Mysql

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Reshad F

Reshad F

14/02/2013 00:56:21
Quote Anchor link
Helloo peeps, Is er een verschil tussen Postgres en Mysql exports? dus stel ik exporteer een database via postgres kan ik deze dan zonder probleem in Mysql importeren? Ik heb namelijk vandaag kennis gemaakt met Postgres en ik wilde een kant en klare export in mijn mysql importeren maar kreeg aldoor foutmeldingen...
 
PHP hulp

PHP hulp

06/12/2024 09:12:53
 
- Raoul -

- Raoul -

14/02/2013 01:07:40
Quote Anchor link
Er is een licht verschil in syntax tussen van MySQL en postgres, dus dat zal niet gaan nee. Daarom dat er zo iets bestaat als migrations (A)
Gewijzigd op 14/02/2013 01:24:04 door - Raoul -
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

14/02/2013 09:30:06
Quote Anchor link
Een licht maar wel belangrijk verschil zoals blijkt.
In Postgres worden kolom- en tabelnamen omsloten door dubbele quotes, als dit met de export ook gebeurd is, dan gaat het niet goed in MySQL.

In Postgres de ID kolommen op de officiële manier zijn gemaakt:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
CREATE SEQUENCE tbl_id;
CREATE TABLE atable (
    id INTEGER NOT NULL
    DEFAULT nextval(tbl_id)
);
dan gaat dit ook niet goed in MySQL.

Zo kan ik nog wel ff doorgaan.
Gewijzigd op 14/02/2013 09:30:34 door Ger van Steenderen
 
Reshad F

Reshad F

14/02/2013 11:57:59
Quote Anchor link
Is er een manier om dit toch te kunnen importeren in een MySQL db of ..?
 
TJVB tvb

TJVB tvb

14/02/2013 12:17:00
Quote Anchor link
Zoek eens op postgresql to mysql migration. Er zijn volgens mij wel tools voor. Maar de vraag is hoeveel tabellen zijn het? Misschien is handmatig wel net zo snel.
 
Reshad F

Reshad F

14/02/2013 12:21:25
Quote Anchor link
Het is niet zo veel het is gewoon dat we voor school opdrachten moeten maken (queries maken) voor bepaalde dingen uit een boek daarvoor gebruikt de school zelf PostgresSQL maar ik gebruik liever MySQL omdat de PostgresSQL teveel dingen wilt van mijn macbook.. zo verandert de database de shared memory etc en maakt zelf een useraccount en allemaal rare dingen.. em vp;gems ,ok zokm de queries in principe hetzelfde toch? alleen hoe het in de database staat kan dus verschillen zoals Ger al zei.. vandaar die errors :)
 
TJVB tvb

TJVB tvb

14/02/2013 12:23:10
Quote Anchor link
Er zit ook wat verschil in query's Dus met alleen de database aanpassen ben je er niet (of je moet mazzel hebben).
 
Reshad F

Reshad F

14/02/2013 12:27:11
Quote Anchor link
Hmm dat is jammer.. dan ga ik het maar bij Postgres houden en hopen dat ik het er niet binnen 1 dag zat ben omdat het mijn macbook overneemt want ik lees er wel hele goede verhalen over op internet.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

14/02/2013 13:01:14
Quote Anchor link
Het is een beetje afhankelijk van hoe de export gemaakt is. Standaard gebruikt Postgres bv COPY ipv INSERT maar dit kan je bv met pgAdmin instellen (Tools -> Backup ..., tabje options#1).
Dan hoef je 'alleen maar' die CREATE SEQUENCE - en de daarmee aanverwante - dingen weg te halen, en de ddl van de tabellen wat aan te aanpassen.

PS.
Voor de nieuwsgierigen naar de verschillen tussen de verschillende db systems, zie hier.
 

19/10/2015 13:09:22
Quote Anchor link
Met de gedachte dat MySQL slechts een applicatie-niveau database is, waar postgres op enterprise niveau betrouwbaar ingezet kan worden, wil ik een van mijn PHP-applicaties ombuigen naar PostgreSQL. (Dat zou toch moeten lukken met PDO? :)

De bestaande MySQL database bevat slechts 51 tabellen met een half duizend kolommen. De recentste PHP-tools beschikbaar vanaf postgres krijgen de conversie niet voor elkaar (errors, out of memory..) dus moet ik het min of meer wel handmatig doen. Niet erg, gaat wat trager en je leert er van.

Ik ben tegen een aantal punten aangelopen, en op punt 4 na kom ik er uit:

1.) In één tabel gebruik ik de simpelste vorm van CDC, namelijk een id met current timestamp, die samen een primary key vorden. De id kan dus vaker voorkomen, elke keer als er iets veranderd is. Maar PostgreSQL kan helaas geen foreign key-relatie bewaken als je alleen maar de id hebt, en niet de timestamp. Dus dat moest ik even aanpassen. Ik heb ook geen idee of MySQL dat wel kan, maar ik wil data handling meer aan de database over laten.

2.) Bij velen bekend: MySQL kan niet-bestaande datums opslaan als datum. Daarvan heb ik gebruik gemaakt met '0000-00-00' als onbestaande datum, om NOT NULL te kunnen gebruiken wat efficiënter zou werken in MySQL. Maar PostgreSQL accepteert alleen geldige data (jeuj :) dus moest ik het overal aanpassen naar '0001-01-01'. Dat ging nog vrij soepel.

3.) PostgreSQL ondersteunt geen SET. Geen probleem, op internet een mooi truukje gevonden:
http://stackoverflow.com/questions/8424283/convert-mysql-set-data-type-to-postgres
CREATE FUNCTION has_unique_values(varchar[]) RETURNS boolean AS $$
SELECT (SELECT COUNT(DISTINCT c) FROM unnest($1) AS dt(c)) = array_length($1, 1);
$$ LANGUAGE sql;
met een CHECK op de kolom en je bent er.

4.) PostgreSQL accepteert geen ENUMs langer dan NAMEDATALEN - 1. Standaard is de uitkomst 63. Lullig als je ENUMs langer zijn. Volgens verschillende bronnen is het niet handig om die parameter te veranderen, omdat ook functienamen etc. beperkt worden tot NAMEDATALEN, en als je die verandert mag je PostgreSQL opnieuw compileren en alle patches en bugfixes nadien opnieuw verzorgen. DUS.... En dan lees ik op sommige sites ook nog van die sufferds die tegen gebruik van ENUM zijn en zeggen dat je dan je database moet normaliseren. Waarom wordt het dan uberhaupt ondersteund?
Is er echt geen andere optie, iets met ALTER SYSTEM dat iemand weet?
 
Ivo P

Ivo P

19/10/2015 14:13:23
 
Thomas van den Heuvel

Thomas van den Heuvel

19/10/2015 14:54:47
Quote Anchor link
An tje op 19/10/2015 13:09:22:
Dat zou toch moeten lukken met PDO? :)

Nice try.


Mja: Deze pagina is het laatst bewerkt op 7 okt 2012 om 19:37.

Als ik hier snel doorheen scan zie ik geregeld een verkeerd gebruik van de database. Alle applicaties komen met regels, als je deze willens en wetens aan je laars lapt, en er gebeurt dan iets onvoorspelbaars, is dat dan de schuld van de applicatie? :/

Wanneer een applicatie echt slecht of onbruikbaar is, zou deze op den duur vanzelf verdwijnen. MySQL is er nog steeds. Daarnaast: MySQL is niet goed of slecht in absolute zin, enkel in het gebruik kan deze beter of slechter zijn.

Tevens: dit soort artikelen/argumenten moet je niet tellen, maar wegen.

Ik kan ook gaan strooien met artikelen waarom PHP bagger zou zijn, maar daar bereik je hier ook weinig mee denk ik.

@Ivo, wat wil je zeggen met deze link?
Gewijzigd op 19/10/2015 15:02:30 door Thomas van den Heuvel
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

19/10/2015 19:14:53
Quote Anchor link
An tje op 19/10/2015 13:09:22:
Dat zou toch moeten lukken met PDO? :)


In dit topic:
An tje op 04/09/2015 11:48:37:
Backticks gebruiken vind ik gewoon een good practice....

Daar zal Postgres blij mee zijn ;-)

Aangaande punt 4:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
CHECK (enumcol IN ('waarde1', 'waarde2', 'waarde3'))
 

20/10/2015 12:06:25
Quote Anchor link
Mja, PostgreSQL snapt geen backticks, daar moet je dubbele aanhalingstekens gebruiken.
Een tikje ongelukkig is dat wel, omdat er wel wat programma's zijn die die tekens automatisch vervangen voor hun unicode variant, waarbij ze een beetje naar binnen staan.
Ben bijna klaar met het eerste conversiebestandje van m'n 50 tabelletjes, 2400 regels lang. Je tikt je het ongans, ik was twee dagen zoet dus heb ik de dubbele quotes maar achterwege gelaten. Behalve dan bij kolommen die beginnen met een cijfer, dat snapt PostgreSQL ook niet anders.
Overigens ben ik nog steeds voor backticks .. bij MySQL, al dan niet gegenereerd. Maar ik snap ook wel dat je soms een evenwicht moet zoeken tussen theorie en praktijk.

Betreft puntje 4, die oplossing is zo enorm simpel, dat ik totaal niet in die richting heb gedacht :)
Bedankt! (scheelt een redelijk aantal vertaaltabellen)

Toevoeging op 20/10/2015 12:24:05:

Overigens, mijn reden om de applicatie eerst op MySQL te bouwen was de algehele beschikbaarheid. Maar nu de applicatie meer enterprise begint te worden voldoet MySQL niet lekker meer.

Daarnaast ben ik Oracle gewoon zat, ze ontwikkelen MySQL toch niet verder tot een volwaardige completere database. Waarom zouden ze met het aangekochte MySQL eigenlijk ook concurreren met hun eigen database? Ik merk het ontmoedigingsbeleid al als ik zoek op http://dev.mysql.com/doc, dan krijg ik allemaal resultaten in het aziatisch terug, terwijl mijn browser gewoon aangeeft dat ik dat niet snap. En het schijnt na de overname niet meer echt vrij te zijn, waardoor MariaDB het licht ziet. Leuke poging, maar wel jammerlijk. Ze hebben ook niet eens de documentatie op orde, je bent dan toch weer afhankelijk van Oracle. Dus afgezien van de beschikbaarheid, wat het grootste voordeel is van MySQL, moest ik op termijn vanzelf een keer over omdat het programma te omvangrijk wordt.

Overigens zou ik ook niet verbaasd zijn als PHP op den duur niet meer voldoet, bijvoorbeeld bij meer gebruik van websockets. Ik zie gebeuren dat dan node.js en PHP eerst naast elkaar draaien, en wanneer het uitkomt zal in mijn applicatie node.js PHP helemaal kunnen vervangen. Dat is overigens nog een reden om zoveel mogelijk database-logica, wat vaak in de controller wordt opgevangen met ORM-tools, toch zoveel mogelijk in de database te houden. Het is niet alleen sneller maar maakt ook dat dan PHP de 'lijm' kan zijn tussen de database en de browser.
 
Ivo P

Ivo P

20/10/2015 13:43:18
Quote Anchor link
ik had de indruk dat je Mysql als de standaard beschouwt en PostgreSQL probeert te gebruiken op een manier die zo veel mogelijk aansluit bij Mysql.

Dit terwijl Mysql nu net een database is, die nogal wat aparte syntax ondersteunt, omdat dat zo leuk lijkt op PHP/Javascript of omdat veel gebruikers dat nu eenmaal zo denken te moeten gebruiken.

Zo zijn de backtic "handig", als je niet lastig gevallen wilt worden met meldingen dat een tabel- of kolomnaam niet gelijk mag zijn aan een gereserveerd woord, of dat er vreemde tekens in staan.

Lijkt me handiger om dan een andere naam te kiezen.
Maar PostgreSQL kan ook zo'n truukje, maar dan met dubbele quotes.

Maar er zijn meer syntax verschillen in de query's.

Waar PostgreSQL een dataset limiteert met LIMIT 10 OFFSET 100
kan Mysql naast deze syntax ook LIMIT 10, 100 gebruiken.

En de aparte insert query INSERT INTO tabel SET kolom1 = 'a', kolom2 = 'b' snappen de meeste andere databases ook niet.

Je moet je bij het schrijven van je query's dus liefst een zo altmeen mogelijke syntax gebruiken. Dat vergemakkelijkt een verhuizing naar een andere database. Maar je zult altijd handmatig een controle moeten doen.
Er is geen "export naar PostgreSQL" of "export naar Oracle" knopje.
 

20/10/2015 16:27:21
Quote Anchor link
PostgreSQL voelt vergeleken met MySQL gewoon aan als een warm bad. In MySQL heb je bijvoorbeeld verschillende table engines. Klinkt leuk, maar in de praktijk wil je niet na hoeven denken over verschillende engines, dan moet het gewoon werken. Bijvoorbeeld het gezeur met InnoDB. Het is in veel opzichten beter dan MyISAM, toch is MyISAM de standaard. Wil je over naar InnoDB, dan moet je opletten op allerlei settings, zoals deze:
SET GLOBAL INNODB_FILE_FORMAT = 'Barracuda';
SET GLOBAL INNODB_FILE_PER_TABLE = 1;
SET GLOBAL INNODB_FILE_FORMAT_MAX = 'Barracuda';
Om niet tegen suffe dingen als een 'row size too large' melding aan te lopen, omdat het default format voor InnoDB 'Antilope' is. Je wilt je er eigenlijk niet mee bezig hoeven houden maar het kan allemaal in MySQL.
PostgreSQL is duidelijk; er zijn geen verschillende engines waar je op hoeft te letten.

Je moet in MySQL ook enorm nadenken over hoe lang je tekst mag zijn, in combinatie met veldtypen als mediumtext en text, vooral omdat de grootte daarvan niet bepaald kan worden door het aantal karakters dat je wilt kunnen gebruiken, maar het aantal bytes. Niet echt handig als je je applicatie van Latin1 naar Unicode wilt tillen. Dit soort dingen laat voor mij duidelijk zien dat MySQL duidelijk meer technisch, en PostgreSQL meer data-georiënteerd is. In PostgreSQL geef je het aantal karakters op. Het klinkt te simpel om waar te zijn, maar het kan echt niet in MySQL.

Gelukkig zijn de veel queries in mijn appje niet handgeschreven maar gegenereerd, en dan hoef je alleen dat stukje code aan te passen. Maar het zal niet van de ene op de andere dag gerealiseerd zijn, het is een vrij omvangrijke rewrite.

Eén nadeel dat ik vond in PostgreSQL is dat van de collaties, daarvoor roept PostgreSQL de API aan op het Windows-systeem, en dan heb ik alleen C, POSIX of Latin1 (US/EN) tot m'n beschikking. MySQL heeft ze wel standaard aan boord, al is de standaard Unicode van MySQL beperkt tot de eerste plane, en moet je lastig doen om de overige tot je beschikking te hebben.
Uiteindelijk heb ik in PostgreSQL maar gekozen voor C, omdat je dan iets meer performance zou krijgen, en collatie in Unicode kan toch alle kanten op. Dan maar elke keer specifieren in de (gegenereerde) query.
Gewijzigd op 20/10/2015 16:48:54 door
 
Pg Vincent

Pg Vincent

31/10/2015 12:37:30
Quote Anchor link
Een beetje laat, maar dit is uiteraard allemaal al lang en breedt uitgewerkt in tools zoals mysql2pgql:

https://pypi.python.org/pypi/py-mysql2pgsql

maak een mysql dump, haal hem door deze tool heen, en importeert het resultaat in postgresql.

Als je alleen de data over wilt zetten, dump de data dan als CSV vanuit MySQL en importeert dat in PostgreSQL met COPY. Snel en eenvoudig.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.