Comparación de tipos de columna de base de datos en MySQL, PostgreSQL y SQLite? (Cross-Mapping)

Question

Estoy tratando de encontrar la forma de relate column types en las bases de datos más utilizadas: MySQL, PostgreSQL y SQLite.

Esto es lo que tengo hasta ahora, pero me temo que no está hecho y necesito algunas personas con más experiencia para ayudarme a terminar cualquier tipo que falte.

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 de cosas que haría de manera diferente:

MEDIUMINT en MySQL es un bicho raro (3 bytes). Yo lo evitaría, pero de lo contrario lo mapearía en INTEGER también.

MySQL BOOLEAN (alias BOOL, alias TINYINT (1)) no es compatible con el tipo booleano pg. Puede o no ser capaz de portar aplicaciones según lo que usen como literales booleanos. En MySQL, los mapas TRUE y FALSE son valores enteros 1 y 0. Parece que el tipo pg BOOLEAN usa una notación literal de cadena. Por lo tanto, las aplicaciones pueden ser portátiles o no, al menos no son reemplazos.

Por último, para la última línea en su tabl creo que la frase SQLite debe decir:

INTEGER PRIMARY KEY AUTOINCREMENT 

Esto es aproximadamente equivalente a

BIGINT PRIMARY KEY AUTO_INCREMENT 

en MySQL. En postgres, los resultados de tipos de datos en serie en una columna INTEGER, y esto sobre la misma que la de MySQL

INTEGER PRIMARY KEY AUTO_INCREMENT 

Postgres también tiene un tipo BIGSERIAL, que es la misma que la serie, pero con un tipo BIGINT en lugar de un tipo INT .

Lo que me faltaba:

me falta entero (INT alias) para MySQL. Es comparable a INTEGER en la pág. omisiones muy importantes: VARCHAR y CHAR. Semánticamente, VARCHAR en MySQL y PG, y CHAR en MySQL y PG son los mismos, pero en MySQL estos tipos tienen una longitud máxima mucho más corta. En MySQL estos tipos pueden tener un máximo de un poco menos de 64 kb, en pg 1Gb (bytes). El especificador de longitud real se expresa en el número de caracteres, por lo que si tiene un conjunto de caracteres de múltiples bytes, debe dividir la longitud máxima por el número máximo de caracteres para obtener la longitud máxima teórica especificada para ese conjunto de caracteres. En SQLite, VARCHAR y CHAR mapa tanto a TEXT

los tipos de datos de bits en MySQL y PG tienen aproximadamente la misma semántica, pero en MySQL la longitud máxima del tipo de datos de bits es 64 (bits)

Creo que la El tipo de datos VARBINARIO de MySQL se puede comparar mejor con el tipo de datos BYTEA de PG. (Pero de hecho tipos BLOB de MySQL también se asignan a eso)

El tipo flotador en MySQL debe ser equivalente a REAL en Postgres (y real en SQLite también) El tipo DECIMAL en MySQL es equivalente a DECIMAL en Postgres, excepto que en postgres, el tipo no impone un límite arbtrary a la precisión, mientras que en MySQL la precisión máxima es (creo) 70. (es decir, 70 posiciones de número) Tanto para MySQL como para Postgres, NUMERIC es un alias para el tipo DECIMAL .