Чи є вагома причина, що я бачу VARCHAR (255), який використовується так часто (на відміну від іншої довжини)?

158

У кількох курсах, книгах та робочих місцях я бачив текстові поля, визначені як VARCHAR (255), як вид за замовчуванням для "короткого" тексту. Чи є якась вагома причина, що довжина 255 вибирається так часто, крім того, що це хороший кругле число ? Це утриманка за деякий час у минулому, коли були вагомі причини (застосовується чи ні сьогодні)?

Звичайно, я усвідомлюю, що більш чітка межа буде більш ідеальною, якщо ви якось знаєте максимальну довжину струни. Але якщо ви використовуєте VARCHAR (255), що, ймовірно, вказує на те, що ви не знаєте максимальної довжини, лише що це "короткий" рядок.

Примітка: я знайшов це питання ( varchar (255) v tinyblob v tinytext ), в якому йдеться про те, що для VARCHAR ( n ) потрібно n +1 байтів зберігання для n <= 255, n +2 байтів сховища для n > 255. Це єдина причина? Це здається чимось довільним, оскільки ви би зберегли лише два байти порівняно з VARCHAR (256), і ви могли так само легко зберегти ще два байти, оголосивши його VARCHAR (253).

— Кіп
джерело

109

Історично склалося, що 255 символів часто були максимальною довжиною a VARCHARв деяких СУБД, і іноді він все ще залишається ефективним максимумом, якщо ви хочете використовувати UTF-8 і індексувати стовпець (через обмеження довжини індексу).

— хаос
джерело

4

@CharlesBretana: якщо ти прочитаєш решту цитованих пропозицій, знайдеш точне пояснення, яке ти вимагаєш.

— хаос

2

@CharlesBretana: Під фальшивим UTF-8 я маю на увазі кодування MySQL "utf8", яке, як я вже згадував, резервує (і обмежується) 3 байтами на символ. Це не дуже хороша версія UTF-8; якщо ви хочете пристойного UTF-8 в MySQL, ви повинні використовувати його "utf8mb4" кодування. Але люди набагато частіше цього не знають і переходять з "utf8", і набагато більше шансів на те, що хочуть UTF-8, ніж будь-яке інше кодування, тому, престо, вони закінчуються з максимальною довжиною, що підлягає індексуванню, 255 символів у VARCHAR. Незважаючи на ваше враження.

— хаос

3

@CharlesBretana: Я зараз це пояснював три рази, і жодна річ не змінилася. Ліміт довжини індексу MySQL все ще становить 767 байт, кількість байтів, необхідних для кодування 3-байтного символу UTF-8, все ще становить 3, а підлога (767/3) все ще 255. Твоя рішучість знайти щось плутати щодо віри жебраків .

— хаос

1

@CharlesBretana (Вибачте, що запізнився на всю цю вечірку) Я не фахівець з БД, але я думаю, що про хаос йдеться так: так, стовпець "Підроблений UTF-8" може містити більше 255 символів, але індекс буде працюйте лише над першими 255 символами варшара, що робить його фактично максимальним стовпцем, якщо ви хочете, щоб він повністю індексувався. Тепер це лише те, що я зрозумів з його пояснень. Можливо, я помиляюся, я взагалі не знавець індексів SQL.

— Лорд Френсіс

2

@CharlesBretana Якщо ви правильно подивитесь на відповідь Хаосу, то помітите, що він розділений на 2 частини: 1. Історична причина, що стоїть за Varchar (255), є настільки поширеною (раніше вона була максимумом у деяких старих СУБД), 2. Навіть сьогодні це обмеження для деяких, оскільки обмеження щодо індексу, про які йшлося раніше, частини 1 та 2 не пов'язані. Частина 1 - це фактична відповідь на питання, частина 2 - це бічна примітка, яка досі є актуальною для цього питання, оскільки вона пояснює, чому навіть сьогодні це може бути обмеженням. (ПРОДОЛЖЕНО ->)

— Франциск Лорд

161

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

Використовуючи цей спосіб, VarChar використовує лише кількість байтів + 1 для зберігання тексту, тому ви можете також встановити його на 255, якщо ви не хочете жорсткого обмеження (наприклад, 50) щодо кількості символів у полі.

— Роберт Харві
джерело

90

Мені подобається ця фраза: "легковажно вимагати ще одного цілого байта". =)

— MusiGenesis

7

Чи справедливо це для БД, де вархарами є UTF-8?

— antak

1

@antak: У MySQL, використовуючи InnoDB, будь-який стовпець ключів не може перевищувати 767 байт. Якщо стовпець VARCHAR дорівнює UTF8 (тобто кожен знак може займати до 3 байт), максимально дозволена довжина стовпця дорівнює підлозі (767/3) = 255. Я припускаю, що "767" був обраний саме з цієї причини.

— BlueRaja - Danny Pflughoeft

1

Якщо діапазон єutf8 , varchar(85)це межа, за яку перетинає підказки довжина байтів від одного до двох байтів. Якщо так utf8mb4, то це varchar(63). Вони є вагомими, оскільки вони є максимальним, до якого довжина VARCHAR може бути збільшена за допомогою використання Інтернет-ТАБЛИЦІ . Отже, я отримав ці числа, створивши таблицю зі varchar(2) charset utf8стовпцем і побачивши, наскільки мені вдалося її розширити ALGORITHM=INPLACE.

— antak

Це має ще більший сенс, якщо врахувати, що багато "баз даних" Back In The Day зберігалися на магнітній стрічці. Було дуже часто читати дані в "блоках", розміри яких були кратні по два. Таким чином, дані зберігалися найефективніше (і коли ви працювали на старому мейнфреймі, такі невеликі показники ефективності були оптимізаціями, що роблять це, або розбийте).

— TMN

23

Можливо, тому, що і SQL Server, і Sybase (щоб назвати два, з якими я знайомий) використовували максимум 255 символів у кількості символів у VARCHARстовпці. Для SQL Server це змінилося у версії 7 у 1996/1997 рр. ... але старі звички іноді важко помирають.

— Чарльз Бретана
джерело

8

+1 для цитування конкретних БД та версій. І «Старі звички вмирають важко» - це, мабуть, найправдістіша відповідь усіх.

— Ендрю М

17

Я збираюся відповісти на буквальне запитання: ні , немає вагомих причин, коли ви бачите VARCHAR (255), який використовується так часто (дійсно є причини , як обговорювалося в інших відповідях, просто не гарні). Ви не знайдете багато прикладів проектів, які катастрофічно зазнали невдачі, оскільки архітектор вибрав VARCHAR (300) замість VARCHAR (255). Це було б проблемою майже тотальної незначуваності, навіть якщо ви говорили про CHAR замість VARCHAR.

— Музигенез
джерело

1 байт з 255 становить 0,4%. Іноді ти піклується про останні півтора відсотків. Іноді ти цього не робиш. Якщо витрати на хостинг та парфюмерию сягають десятків доларів, вам, мабуть, все одно. Якщо вони натрапляють на мільйони, вони, ймовірно, і роблять.

— Едвард Брей

2

@EdwardBrey: якщо закон Мура все ще відповідає дійсності, моя відповідь тут в 16 разів більш достовірна, ніж це було, коли я його писав.

— MusiGenesis

Якщо ми не виявили в 16 разів більше способів, як комп’ютери можуть нам допомогти. Швидкість все ще є особливістю.

— Едвард Брей

14

Коли ви говорите, 2^8що отримуєте 256, але цифри в комп'ютерному виразі починаються з числа 0. Отже, тоді ви отримали тест 255, ви можете перевірити його в інтернет-масці для ІР або в самому IP.

255 - максимальне значення 8-бітного цілого числа: 11111111 = 255

Чи допомагає це?

— exec.-
джерело

1

З цілими числами ви рахуєте починаючи з 0 і закінчуючи в 255. Але місцями в рядку ви рахуєте, починаючи з 1-го місця, тому не має сенсу закінчуватися на 256-му місці, тому що ви починали з 1 замість 0? Я зовсім не згоден з varchar (256), але все-таки через результати string_length (), але я дійсно не впевнений.

— HoldOffHunger

1

@HoldOffHunger рядки в базі даних можуть мати довжину нульових символів, тому допустимий діапазон довжин, коли довжина зберігається у восьми бітах, становить від 0 до 255. Якщо ви хочете сказати, що всі рядки повинні мати принаймні один символ, то ви може підтримувати 256 символьних рядків з восьми бітною довжиною.

— фог

7

Примітка: я знайшов це питання ( varchar (255) v tinyblob v tinytext ), в якому йдеться про те, що для VARCHAR ( n ) потрібно n +1 байтів зберігання для n <= 255, n +2 байтів сховища для n > 255. Це єдина причина? Це здається чимось довільним, оскільки ви би зберегли лише два байти порівняно з VARCHAR (256), і ви могли так само легко зберегти ще два байти, оголосивши його VARCHAR (253).

Ні. Ви не збережете два байти, оголосивши 253. Реалізація varchar - це, швидше за все, лічильник довжини та змінної довжини, невизначений масив. Це означає, що якщо ви зберігаєте "привіт" у варшарі (255), ви займете 6 байт: один байт на довжину (число 5) і 5 байт на п’ять літер.

— Стефано Борині
джерело

3

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

— SingleNegationElimination

так, ти маєш рацію. це залежить від реалізації. Ви повинні перевірити посібник постачальника, щоб побачити, у чому справа

— Стефано Борині

2

Це може бути допустимим, але реалізація VARCHARтаким чином перемагає всю точку використання VARCHARзамість CHAR.

— dan04

4

Непідписаний 1 байт може містити діапазон [0-255] включно. Тож коли ви бачите 255, це здебільшого тому, що програмісти думають в базі 10(отримаєте жарт?) :)

Насправді деякий час 255 був найбільшим розміром, який можна було надати VARCHAR в MySQL, і є переваги використання VARCHAR над TEXT з індексуванням та іншими проблемами.

— гахуа
джерело

4

У багатьох програмах, як-от MsOffice (до версії 2000 або 2002), максимальна кількість символів на клітинку становила 255. Переміщення даних із програм, здатних обробляти більше 255 символів на поле, до / з цих програм, було кошмаром. В даний час ліміт все менше перешкоджає.

— Хоакін Монтес
джерело

2

0000 0000 -> це 8-бітове двійкове число. Цифра представляє біт.

Ви рахуєте так:

0000 0000 → (0)

0000 0001 → (1)

0000 0010 → (2)

0000 0011 → (3)

Кожен біт може мати одне з двох значень: увімкнено або вимкнено. Загальна найвища кількість може бути представлена множенням:

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

Або

2^8 - 1.

Віднімаємо одне, тому що перше число дорівнює 0.

255 може містити трохи (не призначений для каламбуру) значень.

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

— ScottyBlades
джерело

1

Іншою причиною може бути те, що в дуже старих бібліотеках доступу до даних, таких як RDO та ADO (COM-версія не ADO.NET), вам довелося викликати спеціальний метод GetChunk, щоб отримати дані з стовпця з більш ніж 255 символами. Якщо ви обмежили стовпець varchar 255, цей додатковий код не був необхідним.

— Booji Boy
джерело