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...
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:
CREATE SEQUENCE tbl_id;
CREATE TABLE atable (
id INTEGER NOT NULL
DEFAULT nextval(tbl_id)
);
dan gaat dit ook niet goed in MySQL.
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.
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 :)
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.
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.
?
Onbekende gebruiker
19-10-2015 13:09
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?
