Comparaison des types de colonnes de base de données dans MySQL, PostgreSQL et SQLite? (Cross-Mapping)
J'essaie de trouver un moyen de relier les types de colonnes à travers les bases de données les plus utilisées: MySQL , PostgreSQL , et SQLite .
Voici ce que j'ai jusqu'à présent, mais je crains que ce ne soit pas fait et j'ai besoin de personnes avec plus d'expérience pour m'aider à terminer les types manquants.
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
Liste des choses que je ferais différemment:
MEDIUMINT dans MySQL est un canard impair (3 octets). Je l'éviterais, mais sinon, mappez-le sur INTEGER aussi.
MySQL BOOLEAN (alias BOOL, alias TINYINT (1)) n'est pas compatible avec le type booléen pg. Vous pouvez ou non être en mesure de porter des applications en fonction de ce qu'elles utilisent comme littéraux booléens. Dans MySQL, TRUE et FALSE correspondent à des valeurs entières de 1 et 0. Il semble que le type pg BOOLEAN utilise une notation littérale de chaîne. Ainsi, les applications peuvent être portables ou non - au moins ce n'est pas une goutte de remplacement.
Enfin, pour la dernière ligne de votre tabl, je pense que la phrase SQLite devrait se lire:
INTEGER PRIMARY KEY AUTOINCREMENT
C'est à peu près équivalent à
BIGINT PRIMARY KEY AUTO_INCREMENT
dans MySQL. En postgres, le type de données SERIAL se traduit par une colonne INTEGER, et cela sera à peu près le même que celui de MySQL.
INTEGER PRIMARY KEY AUTO_INCREMENT
Postgres a également un type BIGSERIAL, qui est le même que SERIAL mais avec un type BIGINT au lieu d'un type INT.
Ce que j'ai raté:
Il me manque INTEGER (alias INT) pour MySQL. Il est comparable à INTEGER en p. Omissions très importantes: VARCHAR et CHAR. Sémantiquement, VARCHAR dans MySQL et PG, et CHAR dans MySQL et PG sont les mêmes, mais dans MySQL ces types ont une longueur maximale beaucoup plus courte. Dans MySQL, ces types peuvent avoir un maximum d'un peu moins de 64 Ko, en pg 1 Go (octets). Le spécificateur de longueur réelle est exprimé en nombre de caractères, donc si vous avez un jeu de caractères multi-octets, vous devez diviser la longueur maximale par le nombre maximal de caractères pour obtenir la longueur maximale théorique spécifiée pour ce jeu de caractères. Dans SQLite, VARCHAR et CHAR mappent tous les deux sur TEXT
Les types de données BIT dans MySQL et PG ont à peu près la même sémantique, mais dans MySQL la longueur maximale du type de données BIT est de 64 (bits)
Je pense que le type de données MySQL VARBINARY est mieux comparable au type de données BYTEA de PG. (mais en effet, les types BLOB de MySQL sont également mappés à cela)
Le type FLOAT dans MySQL devrait être équivalent à REAL dans postgres (et REAL dans SQLite aussi) Le type DECIMAL dans MySQL est équivalent à DECIMAL dans postgres, sauf que dans postgres, le type n'impose pas de limite arbitraire sur la précision, alors qu'en MySQL la précision maximale est (je crois) 70. (c'est-à-dire 70 positions numériques) Pour MySQL et Postgres, NUMERIC est un alias pour le type DECIMAL.