Lijst met dingen die ik anders zou doen:
MEDIUMINT in MySQL is een vreemde eend in de bijt (3 bytes). Ik zou het vermijden, maar anders ook toewijzen aan INTEGER.
De MySQL BOOLEAN (alias BOOL, alias TINYINT(1) ) is niet compatibel met het pg boolean-type. Afhankelijk van wat ze als booleaanse letterlijke waarden gebruiken, kunt u al dan niet apps porten. In MySQL worden TRUE en FALSE toegewezen aan 1 en 0 integer-waarden. Het lijkt erop dat het pg BOOLEAN-type de letterlijke tekenreeksnotatie gebruikt. Dus apps kunnen al dan niet draagbaar zijn - het is in ieder geval geen vervanging.
Tot slot, voor de laatste regel in je tabl denk ik dat de SQLite-zin zou moeten lezen:
INTEGER PRIMARY KEY AUTOINCREMENT
Dit komt ongeveer overeen met
BIGINT PRIMARY KEY AUTO_INCREMENT
in MySQL. In postgres resulteert het SERIAL-gegevenstype in een INTEGER-kolom, en dit zal ongeveer hetzelfde zijn als MySQL's
INTEGER PRIMARY KEY AUTO_INCREMENT
Postgres heeft ook een BIGSERIAL-type, dat hetzelfde is als SERIAL, maar met een BIGINT-type in plaats van een INT-type.
Wat ik heb gemist:
Ik mis INTEGER (alias INT) voor MySQL. Het is vergelijkbaar met INTEGER in pg.Zeer belangrijke weglatingen:VARCHAR en CHAR. Semantisch zijn VARCHAR in MySQL en PG en CHAR in MySQL en PG hetzelfde, maar in MySQL hebben deze typen een veel kortere maximale lengte. In MySQL kunnen deze typen maximaal iets minder dan 64kb hebben, in pg 1Gb (bytes). De werkelijke lengtespecificatie wordt uitgedrukt in het aantal karakters, dus als je een multi-byte karakterset hebt, moet je de maximum lengte delen door het maximum aantal karakters om de theoretische maximum lengte te krijgen die gespecificeerd is voor die karakterset. In SQLite verwijzen VARCHAR en CHAR beide naar TEXT
De BIT-datatypes in MySQL en PG hebben ongeveer dezelfde semantiek, maar in MySQL is de maximale lengte van het BIT-datatype 64 (bits)
Ik denk dat het MySQL VARBINARY-gegevenstype het best vergelijkbaar is met het BYTEA-gegevenstype van PG. (maar inderdaad, de BLOB-typen van MySQL komen daar ook op overeen)
Het FLOAT-type in MySQL zou gelijk moeten zijn aan REAL in postgres (en ook REAL in SQLite) Het DECIMAL-type in MySQL is gelijk aan DECIMAL in postgres, behalve dat in postgres het type geen willekeurige limiet oplegt aan de precisie, terwijl in MySQL de maximale precisie is (denk ik) 70. (dat wil zeggen 70 nummerposities) Voor zowel MySQL als Postgres is NUMERIC een alias voor het DECIMAL-type.