Confronto dei tipi di colonne del database in MySQL, PostgreSQL e SQLite? (Cross-Mapping)

Question

Sto cercando di trovare un modo per relate column types attraverso i database più utilizzati: , PostgreSQL e SQLite.

Ecco quello che ho finora, ma temo che non sia fatto e ho bisogno di alcune persone con più esperienza per aiutarmi a finire qualsiasi tipo mancante.

MySQL     PostgreSQL   SQLite 

TINYINT     SMALLINT   INTEGER 
SMALLINT    SMALLINT 
MEDIUMINT    INTEGER 
BIGINT     BIGINT 
BIT      BIT     INTEGER 
_______________________________________________________ 

TINYINT UNSIGNED  SMALLINT   INTEGER 
SMALLINT UNSIGNED  INTEGER 
MEDIUMINT UNSIGNED  INTEGER 
INT UNSIGNED   BIGINT 
BIGINT UNSIGNED   NUMERIC(20) 
_______________________________________________________ 

DOUBLE     DOUBLE PRECISION REAL 
FLOAT     REAL    REAL 
DECIMAL     DECIMAL    REAL 
NUMERIC     NUMERIC    REAL 
_______________________________________________________ 

BOOLEAN     BOOLEAN    INTEGER 
_______________________________________________________ 

DATE     DATE    TEXT 
TIME     TIME 
DATETIME    TIMESTAMP 
_______________________________________________________ 

TIMESTAMP DEFAULT  TIMESTAMP DEFAULT TEXT 
NOW()     NOW() 
_______________________________________________________ 

LONGTEXT    TEXT    TEXT 
MEDIUMTEXT    TEXT    TEXT 
BLOB     BYTEA    BLOB 
VARCHAR     VARCHAR    TEXT 
CHAR     CHAR    TEXT 
_______________________________________________________ 

columnname INT   columnname SERIAL INTEGER PRIMARY 
AUTO_INCREMENT        KEY AUTOINCREMENT 

Answer 1

lista delle cose che farei in modo diverso:

MEDIUMINT in MySQL è un anatra dispari (3 byte). Lo eviterei, ma altrimenti lo mapperei anche a INTEGER.

MySQL BOOLEAN (alias BOOL, alias TINYINT (1)) non è compatibile con il tipo booleano pg. Potresti o meno riuscire a portare le app a seconda di cosa usano come valori booleani. In MySQL, TRUE e FALSE mappano a 1 e 0 valori interi. Sembra che il tipo p BOOLEAN usi la notazione letterale stringa. Quindi le app possono essere o non essere portatili - almeno non è un calo nella sostituzione.

Infine, per l'ultima riga nel tabl Penso che la frase SQLite dovrebbe leggere:

INTEGER PRIMARY KEY AUTOINCREMENT 

Questo è più o meno equivalente a

BIGINT PRIMARY KEY AUTO_INCREMENT 

in MySQL. In postgres, i risultati di tipo di dati seriali in una colonna integer e questo sarà circa la stessa del MySQL

INTEGER PRIMARY KEY AUTO_INCREMENT 

Postgres ha anche un tipo bigserial, che è lo stesso come SERIAL ma con un tipo BIGINT invece di un tipo INT .

Quello che ho perso:

mi manca intero (alias INT) per MySQL. È paragonabile a INTEGER in pg. Omissioni molto importanti: VARCHAR e CHAR. Semanticamente, VARCHAR in MySQL e PG, e CHAR in MySQL e PG sono gli stessi, ma in MySQL questi tipi hanno una lunghezza massima molto più breve. In MySQL questi tipi possono avere un massimo di poco meno di 64kb, in pg 1Gb (byte). L'identificatore della lunghezza effettiva è espresso nel numero di caratteri, quindi se hai un set di caratteri multi-byte, devi dividere la lunghezza massima per il numero massimo di caratteri per ottenere la lunghezza massima teorica specificata per quel set di caratteri. In SQLite, VARCHAR e CHAR mappare sia TESTO

I tipi di dati BIT in MySQL e PG hanno all'incirca la stessa semantica, ma in MySQL la lunghezza massima del tipo di dati BIT è 64 (bit)

Credo che il Il tipo di dati VARBINARY di MySQL è meglio paragonabile al tipo di dati BYTEA di PG. (Ma in realtà i tipi BLOB di MySQL mappa anche a quello)

Il tipo FLOAT in MySQL dovrebbe essere equivalente a REAL a postgres (e REAL in SQLite troppo) Il tipo DECIMAL in MySQL è equivalente a decimale in postgres, eccetto che in postgres, il tipo non impone un limite arbitrario alla precisione, mentre in MySQL la precisione massima è (credo) 70. (cioè 70 posizioni di numero) Sia per MySQL che Postgres, NUMERIC è un alias per il tipo DECIMAL .