Длина столбца символов

Question

Какие хорошие правила для определения длины столбца? Люди будут произвольно использовать «VARCHAR (50)» для полей имен и т. Д., Но большая часть этого - работа с догадками. У кого-нибудь есть ресурсы, которые они используют? Какие правила вы придерживаетесь, чтобы определить длину символа? Например, для URL-адреса - он может быть длинным, особенно с учетом строки запроса максимальной длины, - но использование VARCHAR (MAX) кажется чрезмерным, даже если сделать его VARCHAR займет только пространство, требуемое для фактических строковых данных.

Пожалуйста, сообщите / поделитесь -

Answer 1

RFC для таких вещей, как URL-адреса и адреса электронной почты могут быть полезны. URL-адреса имеют ограничение в 2083 символа, а максимальная длина адресов электронной почты - 320 символов (64 для имени, 1 для @ и 255 для домена).

В общем, я ошибаюсь в отношении «слишком длинного» для всего, что хранит пользовательские данные. Для внутреннего использования я стараюсь быть более строгим. Я обычно использую 50 для ключей, 255 для описаний и так далее. Вы не увидите большого влияния на производительность в любом случае, если не будете выполнять поиск или что-то еще, поэтому многие из этих вариантов сводятся к вашим личным предпочтениям.

Короче говоря:

1. Для этих данных существует спецификация (URL, адрес электронной почты и т. Д.): Точнее
2. Данные пользователя: переходите к таким вещам, как имена, устанавливайте разумный предел для таких вещей, как текст комментария
3. Внутреннее использование: все, что плавает на вашей лодке

Answer 2

Ну, обычно я рассматриваю ожидаемую длину самого длинного ввода данных, который я могу представить для поля, а затем обычно добавляю к нему 10-20% в качестве отправной точки, если я не знаю, что данные имеют определенный предел (почтовые индексы имеют определенная длина, например), и я использую это. Если длина в жестком пределе (это должна быть та длина, а не какая-либо другая, я использую тип данных Char, в противном случае я использую varchar или nvarchar для строковых данных.

Answer 3

Что вы пытаетесь оптимизировать? Как указывалось, обычный VARCHAR не имеет большой разницы в стоимости, поэтому для этого не нужно много усилий. Другая причина, по которой вы можете позаботиться о каком-то правиле проверки, в этом случае вам нужно выяснить, что определяет, является ли значение поля действительным или нет. Затем примените это.

Answer 4

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

Будете ли вы иметь много-много-много-много колонок, в которых вы не уверены? Будет ли их изменение позже чудовищной задачей? Если нет, тогда играйте консервативно, и если вы достигнете предела, вы можете расширяться - просто имейте в виду, что вы не хотите, чтобы эти ограничения распространялись по всему вашему коду; насколько это возможно, централизуйте их и применяйте по мере необходимости.

Попробуйте выбрать длину, которая длиннее, чем вы ожидаете, но не полностью исключена. Если это поле, для которого вы думаете, что 25 является разумным, тогда сделайте это 50; если 150 кажется правильным, тогда сделайте 200.

Обычно мы используем nvarchar (100) для имен, 255 для URL-адресов или других полей, которые могут быть длинными (обычно это просто доменные имена, а не полные URL-адреса для определенных страниц / ресурсов сайта). Наш мэйнфрейм налагает аналогичные ограничения, и каждый год мы проводим несколько расширений месторождений, но мы ожидали, что их изменение не составляет особого труда.

Answer 5

Для URL я бы посоветовался с RFC для URL. Имя и фамилия Я обычно пишу со 100 символами - это не имеет значения, как вы сказали, поскольку (N) VARCHAR занимает только необходимое ему место.

То, что я склонен делать:

• Я бы обычно использовал NVARCHAR вместо VARCHAR для имен, так как для многих имен нужны специальные символы.
• Я проверяю, какую бы длину я не выбрал в БД, я также применяю ее в пользовательском интерфейсе.

Answer 6

По крайней мере в mysql служебные данные из поля VARCHAR составляют либо один байт для максимальной ширины до 255 байт, либо два байта для любой большей максимальной ширины. Таким образом, одним хорошим правилом было бы использовать VARCHAR (255), если вы не ожидаете, что ваши данные превысят 255 байт, или VARCHAR (65535) в другом месте.

Конечно, если вы ожидаете, что для данных будет действительно жесткое ограничение, вы можете установить ограничение в определении столбца, чтобы оно действовало как второй уровень проверки данных (но если оно достаточно далеко, чтобы вызвать ошибка базы данных, это следует считать ошибкой на более высоких уровнях).

Источник: http://dev.mysql.com/doc/refman/6.0/en/char.html