Postgres VS Mysql
Gewijzigd op 14/02/2013 01:24:04 door - Raoul -
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)
1
2
3
4
5
6
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.
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
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.
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?
An tje op 19/10/2015 13:09:22:
Dat zou toch moeten lukken met PDO? :)
Nice try.
Ivo P op 19/10/2015 14:13:23:
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
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)
1
CHECK (enumcol IN ('waarde1', 'waarde2', 'waarde3'))
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.
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.
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.
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.