Порівняння типів стовпців бази даних у MySQL, PostgreSQL та SQLite? (Перехресне зіставлення)


77

Я намагаюся знайти спосіб зв’язати типи стовпців у найбільш часто використовуваних базах даних: MySQL , PostgreSQL та SQLite .

Ось те, що я маю на сьогодні, але я боюся, що це не зроблено, і мені потрібні люди з більшим досвідом, які допоможуть мені закінчити будь-які відсутні типи.

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

Я б сказав, і я думаю, що це правда, перехресне картографування типів баз даних не рекомендується, тому що немає (на мої очі) абсолютно жодного часу, який потрібно робити для перехресного картографування. Може трапитися так, що вам доведеться перетворити PG на My, але не перекреслювати їх.
Julius F

2
Чому б не додати SQL Server & Oracle до таблиці?
Дрю Холл

2
Метою цієї перехресної карти типів стовпців є значно спростити пояснення (або навіть використання) CREATE TABLEвизначень між цими трьома типами. Оскільки вони часто використовуються, я виявляю, що відкритий вихідний код повинен бути готовим до будь-якого з них.
Xeoncross

@Xeoncross, можливо, ти міг би оновити свою діаграму з моїми пропозиціями? особливо потрібно додати відсутні елементи INTEGER, VARCHAR, CHAR. Я думаю, що й інші мої пропозиції справедливі, але не настільки важливі.
Роланд Буман

@Roland, вибач із Різдвом, і все, що я був трохи зайнятий. Виправлено.
Xeoncross

Відповіді:


16

Список речей, які я б зробив інакше

MEDIUMINT в MySQL - непарна качка (3 байти). Я б цього уникнув, але в іншому випадку також зіставити його з INTEGER.

MySQL BOOLEAN (псевдонім BOOL, псевдонім TINYINT (1)) не сумісний з pg-булевим типом. Ви можете або не зможете переносити програми залежно від того, що вони використовують як логічні літерали. У MySQL значення TRUE та FALSE відображають цілі значення 1 та 0. Схоже, тип pg BOOLEAN використовує літеральні нотації рядка. Тож програми можуть бути портативними, а можуть і не бути - принаймні, це не падіння заміни.

Нарешті, для останнього рядка у вашому tabl, я думаю, фраза SQLite повинна читати:

INTEGER PRIMARY KEY AUTOINCREMENT

Це приблизно еквівалентно

BIGINT PRIMARY KEY AUTO_INCREMENT

в MySQL. У postgres тип даних SERIAL отримує стовпець INTEGER, і це буде приблизно так само, як у MySQL

INTEGER PRIMARY KEY AUTO_INCREMENT

Postgres також має тип BIGSERIAL, який є таким самим, як SERIAL, але з типом BIGINT замість типу INT.

Що я пропустив:

Мені не вистачає INTEGER (псевдонім INT) для MySQL. Це можна порівняти з INTEGER у стор. Дуже важливі пропуски: VARCHAR та CHAR. Семантично VARCHAR у MySQL та PG та CHAR у MySQL та PG однакові, але в MySQL ці типи мають значно меншу максимальну довжину. У MySQL ці типи можуть мати максимум трохи менше 64 кб, в pg 1 Гб (байти). Специфікатор фактичної довжини виражається в кількості символів, тому, якщо у вас багатобайтовий набір символів, вам доведеться розділити максимальну довжину на максимальну кількість символів, щоб отримати теоретичну максимальну довжину, вказану для цього набору символів. У SQLite VARCHAR і CHAR відображають обидва тексти

Типи даних BIT в MySQL і PG мають приблизно однакову семантику, але в MySQL максимальна довжина типу даних BIT становить 64 (біти)

Я думаю, що тип даних MySQL VARBINARY найкраще порівняний з типом даних BYTEA PG. (але справді типи BLOB-файлів MySQL також співпадають з цим)

Тип FLOAT у MySQL повинен бути еквівалентний REAL у postgres (і REAL у SQLite теж) Тип DECIMAL у MySQL еквівалентний DECIMAL у postgres, за винятком того, що в postgres тип не накладає обмежень на точність, тоді як у MySQL максимальна точність (я вважаю) 70. (тобто 70 позицій чисел) Як для MySQL, так і для Postgres, NUMERIC є псевдонімом для типу DECIMAL.


є ще одна відмінність, у Pg ви використовуєте varchar () лише тоді, коли у вас є розумна причина застосувати обмеження, які він надає. У MySQL ви робите це, щоб мати велику внутрішньо вбудовану крапку тексту, яка швидко працює. У Pg він працює повільніше і займає мою кімнату. У Pg ви майже ніколи не використовуєте varchar ().
Еван Керролл

5
EvanCarrol, це цікаво. Отже, що слід використовувати в pg для зберігання досить дрібних фрагментів тексту, таких як імена людей, назви продуктів, короткі (скажімо, менше 255) описи? просто ТЕКСТ?
Роланд Буман,

3
логічні значення postgres не є типовими рядковими літералами, вони виглядають лише так. якщо ви призначаєте їх цілим числом, що виходить o, 1 або NULL як відповідне, навпаки, якщо у вас є цілі числа 0,1 або NULL, ви можете передати їх у логічне значення. COPY ... FROM приймає цифри, але INSERT потребує явного приведення або лапок навколо номера. так що '0', cast (0 як boolen), 'f' і false буде працювати у вставці, що очікує логічне значення.
user340140
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.