Чи є причина використовувати varchar над текстовими стовпцями в базі даних?

Це varcharлише залишки від того, що textбуло раніше , або є випадки використання, коли ви хочете скористатися varchar? (Або charз цього питання ..)

(Я використовую Postgres та MySQL (MyISAM) щодня, тому саме це мене найбільше цікавить, але відповіді для інших баз даних, звичайно, вітаються. ^ _-)

— Ізката
джерело

Принаймні , для SQL Server , textє застарілим. Існують також міркування щодо використання, пов’язані з тим, де зберігаються дані та яким чином вони отримують доступ до них.

— Oded

У деяких СУБД ви, можливо, не зможете використовувати текстовий стовпець у вигляді або в пункті. Я не знайомий з Postgres, але перевірте вашу документацію.

— jqa

Це запит щодо StackOverflow може надати додаткову інформацію.

— J0ANMM

Відповіді:

Загалом

textстовпці нестандартні та конкретні для впровадження. У багатьох випадках, залежно від бази даних, вони можуть мати поєднання одного або декількох з наступних обмежень: не піддається індексації , не підлягає пошуку та не може бути відсортовано .

У Постгресі

Усі ці типи зберігаються внутрішньо, використовуючи ту саму структуру даних C. .

У MySQL

The textКолона є спеціалізованою версієюBLOB і має обмеження по індексації.

Саме ці два приклади можна екстраполювати на інші системи SQL RDBMS і повинні бути достатньою підставою, щоб зрозуміти, коли вибрати один тип над іншим.

Просто для того, щоб це було чітко зрозуміло, ви ніколи не повинні використовувати, TEXTоскільки це власність і нестандартність. Будь-яке, що SQLви пишете проти цього, не буде портативним і гарантовано викличе вам проблеми в майбутньому. Використовуйте лише типи, що входять до стандарту ANSI .

Використовуйте CHAR коли знаєте, що у вас є фіксована кількість символів для кожного запису.
Використовуйте VARCHAR коли у вас є змінна кількість символів для кожного запису.
Якщо вам потрібно більше місця, ніж VARCHARможете забезпечити, CLOBсUTF-8 кодуванням або аналогічним стандартним типом.
НІКОЛИ не використовуйте, TEXTоскільки це нестандартно.

Прийнятий non standard and implementation specificі not indexable, not searchable and not sortable, чого я не усвідомлював. У мене під враженням text було стандартизовано.

— Ізката

ви маєте на увазі textстандарт ASCII або стандарт UNICODE text:-) або один із інших textстандартів кодування півдесятка ?

якщо ви перекопаєтесь у документах зі стандартами SQL, я не думаю, що ви знайдете щось про textтип символу. Я нічого не бачив, деякі постачальники називають це long charтощо, це в основному BLOB з кодуванням, приєднаним до нього.

@JarrodRoberson, чесно кажучи, існує безліч авторитетних ресурсів, які роблять висновок (коли в середовищі Postgres), який "завжди використовують TEXT". Якщо ви збираєтеся перейти на іншу базу даних, це навряд чи буде порушувач угоди, тим більше, що вам доведеться враховувати, що постгрес "необмежений" VARCHAR(через TOAST немає обмеження рядків, як, наприклад, з MySQL) може не перетворюватися на необмежений VARCHARу інші бази даних все одно.

— Каяман

... і оскільки Postgres не підтримує CLOB , другий і останній пункт не дотримується. Ви ніколи не зможете підтримувати замінні місця, що випадають, навіть якщо дотримуєтесь стандарту. Крім того, як писати ANSI SQL не є життєздатним варіантом у реальному світі, якщо ви не пишете іграшковий SQL.

— Каяман

text, varcharі charвсі вони використовуються з різних причин. Звичайно, існують відмінності у впровадженні (скільки розмірів вони займають .. тощо), але також є питання використання та намірів . Який тип ви використовуєте, також щось говорить про тип даних, які будуть зберігатися в ньому (або ми б всі використовували textдля всього ). Якщо щось має фіксовану довжину, ми використовуємо char. Якщо він має змінну довжину з чітко визначеною верхньою межею, тоді використовуйте varchar. Якщо це великий шматок тексту, над яким ви мало контролюєтесь, textце, мабуть, найкраща ставка.

— Система вниз
джерело

Sooooooo, єдиною реальною різницею є дублювання перевірки меж, яке, мабуть, має бути в програмному коді в будь-якому випадку?

— Ізката

@Izkata - Існують і відмінності в реалізації. Йдеться не про перевірку меж, а про тип даних . Поштовий індекс (США) - це завжди п'ятизначний код, тому використання чогось типу "char" стає частиною визначення цього фрагмента даних. Якби це були лише такі речі, як перевірка прив'язки, ми могли б просто використати один тип даних для всього, і ми зробимо нашу сторону коду перевірки та кастингу.

— Система вниз

@SystemDown Наскільки я знаю, char, varcharі textвсе призначені для зберігання того ж типу даних. Тож обидві відповіді тут стосуються перевірки меж. Якщо існують відмінності в ефективності, які вони? Навіщо мені використовувати varcharбільше text?

— Ізката

float і double також використовуються для одного типу даних, але вони мають відмінності і використовуються по-різному. Що стосується відмінностей у впровадженні, я недостатньо знайомий із Postgres, щоб відповісти, що боюся.

— Запуск системи

@SystemDown Хоча зберігання поштових індексів як знаку (5) може покусити вас, якщо ви почнете інтернаціоналізувати. Поштові індекси у Великобританії різняться за довжиною, і 5 символів майже ніколи не вистачає. Я не знаю, чи пробіл у поштовому індексі Великобританії є релевантним для розбору.

— Ватін

Бази даних сильно переймаються швидкістю продуктивності та мінімізацією пам’яті. У більшості інших частин комп'ютерного світу ви не будете турбуватися про те, скільки символів у вашій рядку символів; це може бути одна, це може бути весь зміст енциклопедії; це все лише рядок. Насправді багато мов навіть не турбують вас про те, чи це рядок чи число.

Але оскільки комп’ютери стають швидшими і отримують більше пам’яті, люди вкладають більше даних у свої бази даних і роблять більш химерні запити. Для процесора та пам'яті бази даних настільки ж обмежують сьогодні, як і в часи основної пам’яті 64 Кб та жорстких дисків 10 Мб (на мейнфреймі комп'ютерів).

Фіксовану кількість байтів набагато простіше впоратися, ніж число зі змінною довжиною. З 10 байтами набагато простіше справитися, ніж з 1 000 000. Таким чином, ваша база даних хоче, щоб ви дали їй підказку, щоб вона могла дати вам гігабайт результатів від терабайт даних в мікросекундах. Якщо ви не використовуєте свою базу даних так важко, вам не знадобиться швидкість, яку вона пропонує, і будете роздратовані непотрібними питаннями. Але якщо вам потрібен виступ, ви будете раді дати йому підказки.

Як зазначається в інших відповідях, використовуйте, charякщо в ньому завжди використовується певна кількість символів, varcharякщо довжина може змінюватися, але вона не надто велика (я думаю , більшість БД трактують це як charабо textзалежно від розміру), і textякщо він може бути будь-якої довжини. Якщо ваш SQL намагається використовувати textстовпчик, можливо, найкраще його якось узагальнити і помістити в charневеликий varcharстовпчик, а потім виконайте whereз цим і order byі. Звичайно, це лише в тому випадку, якщо для вас важлива продуктивність.

— RalphChapin
джерело