MySQL、PostgreSQL 和 SQLite 中数据库列类型的比较？（交叉映射）

Comparison of database column types in MySQL, PostgreSQL, and SQLite? (Cross-Mapping)

提问by Xeoncross

I am trying to find some way to relate column typesacross the the most used Databases: MySQL, PostgreSQL, and SQLite.

我试图找到某种方法来关联最常用的数据库中的列类型：MySQL、PostgreSQL和SQLite。

Here is what I have so far, but I'm afraid it's not done and I need some people with more experience to help me finish any missing types.

这是我到目前为止所拥有的，但恐怕还没有完成，我需要一些有更多经验的人来帮助我完成任何缺失的类型。

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

采纳答案by Roland Bouman

List of things I'd do differently:

我会做不同的事情列表：

MEDIUMINT in MySQL is an odd duck (3 bytes). I would avoid it, but otherwise map it to INTEGER too.

MySQL 中的 MEDIUMINT 是一个奇怪的鸭子（3 个字节）。我会避免它，但也将它映射到 INTEGER。

The MySQL BOOLEAN (alias BOOL, alias TINYINT(1) ) is not compatible with the pg boolean type. You may or may not be able to port apps depending on what they use as boolean literals. In MySQL, TRUE and FALSE map to 1 and 0 integer values. It looks like the pg BOOLEAN type uses string literal notation. So apps may or may not be portable - at least it is no drop in replacement.

MySQL BOOLEAN（别名 BOOL，别名 TINYINT(1) ）与 pg 布尔类型不兼容。您可能会或可能无法移植应用程序，具体取决于它们用作布尔文字的内容。在 MySQL 中，TRUE 和 FALSE 映射到 1 和 0 整数值。看起来 pg BOOLEAN 类型使用字符串文字表示法。所以应用程序可能是也可能不是便携式的——至少它不是替代品。

Finally, for the last line in your tabl I think the SQLite phrase should read:

最后，对于表格中的最后一行，我认为 SQLite 短语应为：

INTEGER PRIMARY KEY AUTOINCREMENT

This is roughly equivalent to

这大致相当于

BIGINT PRIMARY KEY AUTO_INCREMENT

in MySQL. In postgres, the SERIAL datatype results in an INTEGER column, and this will about the same as MySQL's

在 MySQL 中。在 postgres 中，SERIAL 数据类型产生一个 INTEGER 列，这与 MySQL 的大致相同

INTEGER PRIMARY KEY AUTO_INCREMENT

Postgres also has a BIGSERIAL type, which is the same as SERIAL but with a BIGINT type instead of an INT type.

Postgres 也有一个 BIGSERIAL 类型，它与 SERIAL 相同，但使用 BIGINT 类型而不是 INT 类型。

What I missed:

我错过了什么：

I am missing INTEGER (alias INT) for MySQL. It is comparable to INTEGER in pg. Very important omissions: VARCHAR and CHAR. Semantically, VARCHAR in MySQL and PG, and CHAR in MySQL and PG are the same, but in MySQL these types have a much shorter maximum length. In MySQL these types can have a maximum of a little less than 64kb, in pg 1Gb (bytes). The actual length specifier is expressed in the number of characters, so if you have a multi-byte character set, you have to divide the maximum lenght by the maximum number of characters to get the theoretical maximum length specified for that characterset. In SQLite, VARCHAR and CHAR map both to TEXT

我缺少 MySQL 的 INTEGER（别名 INT）。它与 pg 中的 INTEGER 相当。非常重要的遗漏：VARCHAR 和 CHAR。在语义上，MySQL 和 PG 中的 VARCHAR 以及 MySQL 和 PG 中的 CHAR 是相同的，但在 MySQL 中，这些类型的最大长度要短得多。在 MySQL 中，这些类型的最大值可以略小于 64kb，以 pg 1Gb（字节）为单位。实际长度说明符以字符数表示，因此如果您有一个多字节字符集，则必须将最大长度除以最大字符数才能获得为该字符集指定的理论最大长度。在 SQLite 中，VARCHAR 和 CHAR 都映射到 TEXT

The BIT datatypes in MySQL and PG have roughly the same semantics, but in MySQL the maximum length of the BIT data type is 64 (bits)

MySQL 和 PG 中的 BIT 数据类型语义大致相同，但在 MySQL 中 BIT 数据类型的最大长度为 64（位）

I think the MySQL VARBINARY data type is best comparable to PG's BYTEA datatype. (but indeed MySQL's BLOB types also map to that)

我认为 MySQL VARBINARY 数据类型最能与 PG 的 BYTEA 数据类型相媲美。（但确实 MySQL 的 BLOB 类型也映射到那个）

The FLOAT type in MySQL should be equivalent to REAL in postgres (and REAL in SQLite too) The DECIMAL type in MySQL is equivalent to DECIMAL in postgres, except that in postgres, the type does not impose an arbtrary limit on the precision, whereas in MySQL the maximum precision is (i believe) 70. (that is, 70 number positions) For both MySQL and Postgres, NUMERIC is an alias for the DECIMAL type.

MySQL 中的 FLOAT 类型应该等同于 postgres 中的 REAL（以及 SQLite 中的 REAL） MySQL 中的 DECIMAL 类型等同于 postgres 中的 DECIMAL，除了在 postgres 中，该类型不强加对精度的任意限制，而在MySQL 的最大精度是（我相信）70。（即 70 个数字位置）对于 MySQL 和 Postgres，NUMERIC 是 DECIMAL 类型的别名。