PostgreSQL: різниця між текстом і варшаром (характер змінюється)

Яка різниця між textтипом даних та типом даних character varying( varchar)?

Відповідно до документації

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

і

Крім того, PostgreSQL надає текстовий тип, який зберігає рядки будь-якої довжини. Хоча текст типу не входить у стандарт SQL, його мають і деякі інші системи управління базами даних SQL.

То яка різниця?

Там немає ніякої різниці, під капотом все це varlena( масив змінної довжини ).

Перегляньте цю статтю від Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

Кілька важливих моментів:

Підсумовуючи все це:

• char (n) - займає занадто багато місця при роботі зі значеннями, меншими за n(прокладки їх n), і може призвести до тонких помилок через додавання пробілів, плюс змінити обмеження проблематично
• varchar (n) - змінити ліміт у прямому середовищі проблематично (вимагає ексклюзивного блокування під час зміни таблиці)
• варчар - так само, як текст
• текст - для мене переможець - понад (n) типів даних, тому що у них відсутні проблеми, а над varchar - тому що він має чітку назву

У статті робиться детальне тестування, щоб показати, що продуктивність вставлень та вибору для всіх 4 типів даних однакова. Він також детально розглядає альтернативні способи обмеження довжини при необхідності. Обмеження або домени на основі функцій забезпечують перевагу миттєвого збільшення обмеження довжини, і виходячи з того, що зменшення обмеження довжини рядка зустрічається рідко, Депес робить висновок, що один з них, як правило, є найкращим вибором для обмеження довжини.

Як « типажі » в точках документації з, varchar(n), char(n), і textзберігаються всі точно так же. Єдина відмінність - додаткові цикли потрібні для перевірки довжини, якщо вона дана, і додатковий простір та час, необхідні для оббивки char(n).

Однак, коли вам потрібно зберігати лише один символ, є незначна перевага у виконанні використання спеціального типу "char"(зберігайте подвійні лапки - вони є частиною назви типу). Ви отримуєте швидший доступ до поля, і немає накладних витрат, щоб зберігати довжину.

Щойно я склав таблицю з 1 000 000 випадкових випадків, "char"вибраних з малих букв. Запит на отримання розподілу частоти ( select count(*), field ... group by field) займає близько 650 мілісекунд проти 760 за тими ж даними за допомогою textполя.

ОНОВЛЕННЯ БЕНХАРКІВ НА 2016 рік (pg9,5 +)

І з використанням "чистого SQL" орієнтирів (без зовнішнього сценарію)

1. використовувати будь-який string_generator з UTF8

2. основні орієнтири:

   2.1. ВСТУПИТИ

   2.2. ВИБІРТЕ порівняння та підрахунок

CREATE FUNCTION string_generator(int DEFAULT 20,int DEFAULT 10) RETURNS text AS $f$
  SELECT array_to_string( array_agg(
    substring(md5(random()::text),1,$1)||chr( 9824 + (random()*10)::int )
  ), ' ' ) as s
  FROM generate_series(1, $2) i(x);
$f$ LANGUAGE SQL IMMUTABLE;

Підготуйте конкретний тест (приклади)

DROP TABLE IF EXISTS test;
-- CREATE TABLE test ( f varchar(500));
-- CREATE TABLE test ( f text); 
CREATE TABLE test ( f text  CHECK(char_length(f)<=500) );

Проведіть базовий тест:

INSERT INTO test  
   SELECT string_generator(20+(random()*(i%11))::int)
   FROM generate_series(1, 99000) t(i);

І інші тести,

CREATE INDEX q on test (f);

SELECT count(*) FROM (
  SELECT substring(f,1,1) || f FROM test WHERE f<'a0' ORDER BY 1 LIMIT 80000
) t;

... І використовувати EXPLAIN ANALYZE.

ОНОВЛЕНО ПРОТИ 2018 (стор. 10)

трохи редагувати, щоб додати результати 2018 року та посилити рекомендації.

Результати у 2016 та 2018 роках

Мої результати, в середньому, на багатьох машинах і в багатьох тестах: все одно
(статистично менше стандартного відхилення).

Рекомендація

• Використовуйте textтип даних,
  уникайте старих, varchar(x)оскільки іноді це не є стандартом, наприклад, у CREATE FUNCTIONпунктах varchar(x)≠varchar(y) .

• виражати обмеження (з однаковою varcharефективністю!) за допомогою CHECKпункту CREATE TABLE
  напр CHECK(char_length(x)<=10).
  Маючи незначну втрату продуктивності в INSERT / UPDATE, ви також можете контролювати діапазони та структуру рядків,
  наприкладCHECK(char_length(x)>5 AND char_length(x)<=20 AND x LIKE 'Hello%')

У посібнику PostgreSQL

Немає різниці в продуктивності між цими трьома типами, окрім збільшення місця на зберігання при використанні пустого типу та декількох додаткових циклів процесора для перевірки довжини під час зберігання в стовпчику з обмеженою довжиною. Хоча персонаж (n) має переваги у роботі в деяких інших системах баз даних, у PostgreSQL такої переваги немає; насправді персонаж (n), як правило, найповільніший з трьох через його додаткові витрати на зберігання. У більшості ситуацій замість цього слід використовувати текст чи символи, що змінюються.

Я зазвичай використовую текст

Посилання: http://www.postgresql.org/docs/current/static/datatype-character.html

На мою думку, varchar(n)це має свої переваги. Так, всі вони використовують один і той же базовий тип і все таке. Але, слід зазначити, що індекси в PostgreSQL мають обмеження розміру 2712 байт на рядок.

TL; DR: Якщо ви використовуєте textтип без обмежень і маєте індекси в цих стовпцях, цілком можливо, що ви досягнете цього обмеження для деяких своїх стовпців і отримаєте помилку при спробі вставки даних, але при використанні varchar(n)ви можете це запобігти.

Ще кілька деталей: Проблема тут полягає в тому, що PostgreSQL не дає жодних винятків при створенні індексів для textтипу або varchar(n)там, де nвін перевищує 2712. Однак він помилиться при спробі вставки запису зі стислим розміром більше 2712. Це означає, що ви можете легко вставити 100 000 символів рядка, який складається з повторюваних символів, тому що він буде стиснений далеко нижче 2712, але ви, можливо, не зможете вставити рядок з 4000 символів, оскільки стислий розмір перевищує 2712 байт. Використовуючи varchar(n)там, де nне занадто багато, ніж 2712, ви захищені від цих помилок.

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

select ' '::char = ' '::varchar, ' '::char = ' '::text, ' '::varchar = ' '::text

повернення, true, false, trueа не так, true, true, trueяк ви могли очікувати.

Дещо OT: Якщо ви використовуєте Rails, стандартне форматування веб-сторінок може бути іншим. Для форм введення даних textполя прокручуються, але поля character varying(Рейки string) - однорядкові. Показувати перегляди потрібно стільки, скільки потрібно.

Хороше пояснення від http://www.sqlines.com/postgresql/datatypes/text :

Єдина відмінність TEXT від VARCHAR (n) полягає в тому, що ви можете обмежити максимальну довжину стовпця VARCHAR, наприклад, VARCHAR (255) не дозволяє вставляти рядок довжиною більше 255 символів.

І TEXT, і VARCHAR мають верхню межу в 1 Gb, і різниця в продуктивності між ними (відповідно до документації PostgreSQL) не існує.

character varying(n), varchar(n)- (Обидва однакові). значення буде усічене до n символів, не викликаючи помилки.

character(n), char(n)- (Обидва однакові). фіксованої довжини і буде прокладати заготовками до кінця довжини.

text- Необмежена довжина.

Приклад:

Table test:
   a character(7)
   b varchar(7)

insert "ok    " to a
insert "ok    " to b

Отримуємо результати:

a        | (a)char_length | b     | (b)char_length
----------+----------------+-------+----------------
"ok     "| 7              | "ok"  | 2