Список стандартных длин для полей базы данных


395

Я создаю таблицу базы данных и снова задаю себе тот же глупый вопрос: как долго должно быть поле имени?

У кого-нибудь есть список разумных длин для наиболее распространенных полей , таких как имя, фамилия и адрес электронной почты?


1
Просто убедитесь, что вы разрешаете использование не-буквенных символов в именах! указывает на дефис в своей фамилии
Крис Марасти-Георг

3
См. «Максимальная длина действительного идентификатора электронной почты» для определения максимальной длины адреса электронной почты.
outis

2
Одно замечание: не требуется ни «имя», ни «фамилия». У некоторых людей, как и у меня, есть только одно имя. (Доказательство: web.archive.org/web/20130115074449/http://saizai.com/… )
Саи,

А как насчет URL, например, блог или ссылка на профиль?
Алик Эльзин-килака

Прикрутил, если имя так же долго, как этот gintama.wikia.com/wiki/Jugem_Jugem
絢 瀬 絵 里

Ответы:


35

Рекомендация W3C:

При разработке формы или базы данных, которая будет принимать имена от людей с различным происхождением, вы должны спросить себя, действительно ли вам нужно иметь отдельные поля для имени и фамилии.

... Имейте в виду, что имена в некоторых культурах могут быть намного длиннее, чем ваши собственные. … Избегайте ограничения размера поля для имен в вашей базе данных . В частности, не думайте, что четырехзначное японское имя в UTF-8 будет вмещаться в четыре байта - вам, вероятно, действительно понадобится 12.

https://www.w3.org/International/questions/qa-personal-names

Для полей базы данных VARCHAR(255)это безопасный выбор по умолчанию, если только у вас нет веской причины использовать что-то еще. Для типичных веб-приложений производительность не будет проблемой. Не преждевременно оптимизировать.


26
Прошло 10 лет с тех пор, как я задал этот вопрос. Имея за плечами еще 10 лет опыта, я склонен согласиться с вами.
Патрик МакЭлхани

2
Как именно вы напечатаете имя длиной 255 символов на конверте?
Майкл Поттер

316

Я только что запросил свою базу данных с миллионами клиентов в США.

  • Максимальная длина имени была 46. Я иду с 50. (Конечно, только 500 из них были старше 25, и все они были случаями, когда импорт данных приводил к тому, что в этом поле оказывался дополнительный мусор).

  • Фамилия была похожа на имя.

  • Максимальное количество адресов электронной почты составляет 62 символа. Большинство из них были списками адресов электронной почты, разделенными точками с запятой.

  • Максимальный адрес улицы составляет 95 символов. Длинные были действительны.

  • Максимальная длина города была 35.

Это должно быть приличное статистическое распространение для людей в США. Если вам нужно учесть локализацию, цифры могут значительно отличаться.


4
По сравнению с вашими базы данных, к которым у меня есть доступ, крошечные, но даже там я нашел адрес электронной почты из 138 символов. Компонент localpart, очевидно, является своего рода отличительным именем LDAP (или AD?).
Бернд Джендриссек

2
Как насчет телефонных номеров?
Кейвинг

@EricZBeard Включает ли "почтовый адрес" номер дома?
noɥʇʎԀʎzɐɹƆ

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

1
@MGOwen Во-первых, вы не знаете назначение базы данных, в некоторых случаях кому-то отказывают в доступе из-за несерьезной проблемы, например, из-за того, что электронная почта слишком длинная, может быть серьезной проблемой. Во-вторых, ссылка, которую вы разместили, гласит: «Самая длинная действительная - 89», где, как эта говорит, что это 62. Что правильно? Если вы просто хотите выбрать произвольное число или у вас есть веская причина, например, имя должно быть указано как часть адреса, хорошо. Однако все же разумно, что, если вы сомневаетесь, вы обращаетесь к спецификации. Я до сих пор считаю, что один человек, который говорит, что «моя база данных достигает максимума в точке x», является анекдотичным.
Марио

171

В британском правительственном каталоге стандартов данных подробно описываются стандарты Великобритании для такого рода вещей. Он предлагает 35 символов для каждого из заданного имени и фамилии, или 70 символов для одного поля для хранения полного имени, и 255 символов для адреса электронной почты. Среди других вещей..


3
Потребности ссылки будут обновляться по состоянию на 22 октября 2010 года я гугл на: сайте: * gov.uk название «35 знаков» и нашел этот док. Justice.gov.uk/guidance/docs/electoral-reg-standards.pdf
Тони Р

20
Просто мысль ... не должно ли это быть 71 символом для имени и фамилии в одном поле, учитывая, что должен быть пробел?
Джозеф Редферн

8
Ну, они явно ожидают случайное длинное имя (до 35 символов) и случайную длинную фамилию (до 35 символов), но не обязательно ожидают человека с комбинацией длинного имени и фамилии. Это было бы просто жадным ;-)
Ян Нельсон

6
Если мистер Эль-Тахир-эль-Фадиль-эль-Сиддиг Абдеррахман Мохаммед Ахмед Абдель Карим Эль-Махди действительно использует все свои имена при заполнении онлайн-форм, я был бы впечатлен. У меня есть два отчества, но я использую только одно из них, кроме официальных (то есть правительственных) форм.
Леон

2
@ ian-nelson Длина электронной почты в соответствии с RFC 3696: это ограничение составляет не более 64 символов (октетов) в «локальной части» (до «@») и не более 255 символов (октетов) в доменной части (после «@») общей длиной 320 символов. Системы, обрабатывающие электронную почту, должны быть готовы обрабатывать такие длинные адреса, даже если они встречаются редко.
Петр Наврот

54

Некоторые, вероятно, правильные длины столбцов

                            Min Max

Hostname                    1   255
Domain Name                 4   253
Email Address               7   254
Email Address [1]           3   254
Telephone Number            10  15      
Telephone Number [2]        3   26  
HTTP(S) URL w domain name   11  2083        
URL [3]                     6   2083    
Postal Code [4]             2   11
IP Address (incl ipv6)      7   45
Longitude                   numeric 9,6
Latitude                    numeric 8,6
Money[5]                    numeric 19,4

[1] Allow local domains or TLD-only domains
[2] Allow short numbers like 911 and extensions like 16045551212x12345
[3] Allow local domains, tv:// scheme
[4] http://en.wikipedia.org/wiki/List_of_postal_codes. Use max 12 if storing dash or space
[5] http://stackoverflow.com/questions/224462/storing-money-in-a-decimal-column-what-precision-and-scale

Долгая разглагольствование на личные имена

Личное имя - это Полином (имя с несколькими сортируемыми компонентами), Mononym (имя только с одним компонентом), либо Pictonym (имя, представленное картинкой - оно существует благодаря таким людям, как Prince).

У человека может быть несколько имен, играющих роли, таких как ЮРИДИЧЕСКИЕ, МОРСКИЕ, ДЕВУШКИ, ПРЕДПОЧТИТЕЛЬНЫЕ, СОБРИКЕТ, ПСЕВДОНИМ и т.д. вовремя".

Некоторые примеры:

names: [
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"George",
    middle:"Herman",
    moniker:"Babe",
    surname:"Ruth",
    generation:"JUNIOR"
  },
  {
    type:"MONONYM",
    role:"SOBRIQUET",
    mononym:"The Bambino" /* mononyms can be more than one word, but only one component */
  },
  {
    type:"MONONYM",
    role:"SOBRIQUET",
    mononym:"The Sultan of Swat"
  }
]

или

names: [
  {
    type:"POLYNYM",
    role:"PREFERRED",
    given:"Malcolm",
    surname:"X"
  },
  {
    type:"POLYNYM",
    role:"BIRTH",
    given:"Malcolm",
    surname:"Little"
  },
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"Malik",
    surname:"El-Shabazz"
  }
]

или

names:[
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"Prince",
    middle:"Rogers",
    surname:"Nelson"
  },
  {
    type:"MONONYM",
    role:"SOBRIQUET",
    mononym:"Prince"
  },
  {
    type:"PICTONYM",
    role:"LEGAL",
    url:"http://upload.wikimedia.org/wikipedia/en/thumb/a/af/Prince_logo.svg/130px-Prince_logo.svg.png"
  }
]

или

names:[
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"Juan Pablo",
    surname:"Fernández de Calderón",
    secondarySurname:"García-Iglesias" /* hispanic people often have two surnames. it can be impolite to use the wrong one. Portuguese and Spaniards differ as to which surname is important */
  }
]

Заданные имена, отчества, фамилии могут быть несколькими словами, такими как "Billy Bob" Thornton, или Ralph "Vaughn Williams".


5
Это очень информативный, но не очень полезный ответ. В следующий раз, когда мне понадобится «вероятно правильный» ответ, я дам вам знать.
n8bar

16

Я бы сказал, чтобы ошибаться на высокой стороне. Поскольку вы, вероятно, будете использовать varchar, любое дополнительное пространство, которое вы разрешите, не будет фактически занимать дополнительное пространство, если кому-то это не нужно. Я бы сказал, что для имен (первых или последних) нужно набрать не менее 50 символов, а для адреса электронной почты - не менее 128. Есть несколько очень длинных адресов электронной почты.

Еще одна вещь, которую я люблю делать - это зайти на Lipsum.com и попросить его сгенерировать текст. Таким образом, вы сможете получить представление о том, как выглядит 100 байт.


6
О, мой - первый человек, который заметил, что большие поля не обязательно означают больше места для хранения, следовательно, "var" в varchar. NVarchar обычно имеет больше смысла для имен, хотя.
Тао

Зависит от реализации. Вам не нужен NVARCHAR, если VARCHAR поддерживает UTF-8.
Ден04

2
[N]VarcharРазмеры , однако, влияют на ваши индексы.
RBarryYoung

11

Я почти всегда использую степень 2, если нет веской причины не делать этого, например интерфейс пользователя, где какой-то другой номер имеет особое значение для клиента.

Если вы придерживаетесь степеней 2, это удерживает вас в ограниченном наборе общих размеров, что само по себе хорошо, и позволяет легче угадать размер неизвестных объектов, с которыми вы можете столкнуться. Я вижу, что немало других людей делают это, и в этом есть что-то эстетическое. Обычно это вызывает у меня хорошее чувство, когда я вижу это, это означает, что дизайнер думал как инженер или математик. Хотя, возможно, меня беспокоит, если бы использовались только простые числа. :)


3
Можно утверждать, что 2ⁿ - 1, 2ⁿ - 2 или даже 2ⁿ - 4, два были бы лучшим инженерным решением, потому что часто строки представляются как массивы символов с нулевым индексом и заканчиваются нулевым символом, байтом или двумя байтами (UTF-8 ). Также для некоторых баз данных, превышающих 255 для varchar, требуется дополнительный байт для хранения (см. Stackoverflow.com/questions/2340639/… ).
Карманы и

4

Я хотел найти то же самое, и стандарты данных правительства Великобритании, упомянутые в принятом ответе, звучали идеально. Однако, похоже, что ничего из этого больше не существует - после продолжительного поиска я нашел его в архиве здесь: http://webarchive.nationalarchives.gov.uk/+/http://www.cabinetoffice.gov.uk/govtalk/ schemasstandards / e-gif / datastandards.aspx . Нужно скачать zip, распаковать его и затем открыть default.htm в папке html.



2
+------------+---------------+---------------------------------+
|   Field    | Length (Char) |           Description           |
+------------+---------------+---------------------------------+
|firstname   | 35            |                                 |
|lastname    | 35            |                                 |
|email       | 255           |                                 |
|url         | 60+           | According to server and browser |
|city        | 45            |                                 |
|address     | 90            |                                 |
+------------+---------------+---------------------------------+

Изменить : добавлен интервал


1
Почему бы просто не использовать VARCHAR 255 для всего, что является строкой? VARCHAR не использует заполнение и заканчивается дополнительным одним или двумя байтами.
Радтек

varchar может быть немного медленным.
KTA

1

Просто просматривая мои почтовые архивы, есть много довольно длинных «первых» имен (конечно, то, что подразумевается под первым, зависит от культуры). Одним из примеров является Кришнамурти, длина которого составляет 13 букв. На основании этого можно предположить, что от 20 до 25 букв. Адрес электронной почты должен быть намного длиннее, поскольку у вас может быть firstname.lastname@somedomain.com. Кроме того, gmail и некоторые другие почтовые программы позволяют вам использовать firstname.lastname+sometag@somedomain.com, где «sometag» - это то, что вы хотите поместить туда, чтобы вы могли использовать его для сортировки входящих писем. Я часто сталкиваюсь с веб-формами, которые не позволяют мне ввести свой полный адрес электронной почты без учета каких-либо тегов. Итак, если вам нужно фиксированное поле электронной почты, может быть что-то вроде 25.25+15@20.3 в символах, в общей сложности 90 символов (если я правильно сделал свою математику!).


0

Я обычно иду с:

Имя : 30 символов
Фамилия : 30 символов
Электронная почта : 50 символов
Адрес : 200 символов

Если меня беспокоят длинные поля для имен, я мог бы иногда использовать и 50 для полей имен, поскольку в наши дни пространство для хранения данных редко является проблемой.


11
50 за электронную почту? 254 это максимум на самом деле
Марко

0

Если вам нужно учитывать локализацию (для тех из нас, кто находится за пределами США!) И это возможно в вашей среде, я бы посоветовал:

Определите типы данных для каждого компонента имени - ПРИМЕЧАНИЕ: некоторые культуры имеют более двух имен! Затем введите тип для полного имени,

Тогда локализация становится простой (что касается имен).

То же самое относится и к адресам, кстати - разные форматы!


-1

это varchar верно? Так что тогда не имеет значения, используете ли вы 50 или 25, лучше быть в безопасности и использовать 50, что говорит, что я считаю, что самое длинное, что я видел, это около 19 или около того. Фамилии длиннее

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.