Рекомендации по общим полям человека (имя, адрес электронной почты, адрес, пол и т. Д.) [Закрыто]

Каковы наиболее распространенные рекомендации по длине и типу данных для общих полей, таких как:

  • Имя
  • Фамилия
  • Адрес
  • Email
  • Пол
  • Государство
  • Город
  • Страна
  • Номер телефона

и т. д.

42 голоса | спросил Snow_Mac 11 J000000Monday11 2011, 20:10:38

6 ответов


49

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

  • First & amp; фамилия: Почему вы записываете имя? Если у вас есть требование зафиксировать полное юридическое имя человека (то есть вы готовите юридические документы или свидетельства о рождении), вы, вероятно, захотите предоставить больше места для людей, чем вы, если вы просто просите имя человека, чтобы вы имейте что-то, чтобы называть их в новом веб-приложении.
  • Адрес: Что вы собираетесь делать с адресом? Какие адреса вы храните? Если вы храните адрес собственности в Соединенных Штатах, в котором вы создаете ипотеку, вы, вероятно, очень заботитесь о получении полностью стандартизованного адреса, и в этом случае модель данных, вероятно, захочет внимательно изучить любой ваш адрес инструмент стандартизации возвращается. Если вы просто хотите, чтобы люди могли вводить адрес для доставки продукта, достаточно нескольких строк для текста свободной формы. Длина линий там может зависеть от требований последующих процессов, которые делают такие вещи, как метки адреса печати. ​​
  • Состояние. Предполагая, что вы можете определить допустимые значения состояния, вероятно, имеет смысл создать таблицу STATE и создать отношение внешнего ключа между STATE и ADDRESS . Но способность идентифицировать действительные значения подразумевает, что вы ограничиваете набор действительных адресов, по крайней мере, определенным конкретным набором стран. Это хорошо для многих сайтов, но затем вам нужно немного поработать, чтобы поддержать новую страну.
  • Город: Если вы имеете дело с данными, в которых существуют потенциальные правила на уровне города (т. е. существуют разные виды ставок налога, которые применяются на основе города), вы можете захотеть относиться к нему так же, как к государству и иметь таблицу CITY с действительными городами и зависимость внешнего ключа между таблицами CITY и ADDRESS . С другой стороны, если вы просто пытаетесь получить доставленный продукт, и вам не все равно, есть ли у вас разные версии одного и того же города в вашей таблице, что позволяет пользователю вводить текст в свободной форме. Конечно, если вы храните внешние ключи, у вас будет достаточная работа, чтобы убедиться, что у вас есть все допустимые значения. Но есть продукты, в которых все дело в том, что компания уже сделала эту работу (т. Е. Базы данных по налогу на прибыль).
  • Телефон: Что вы делаете с телефонными номерами и почему? Некоторые приложения захотят принимать телефонные номера в любом формате, который пользователь решит ввести и сохранить это форматирование для всех последующих запросов. Это было бы обычным явлением, если вы разрабатываете персональную адресную книгу, где пользователи имеют свои собственные предпочтения в отношении того, как номера телефонов сохраняются и отображаются. Другие приложения хотели бы игнорировать введенное форматирование, извлекать только числовые символы, а затем форматировать данные для извлечения, чтобы все номера телефонов имели схожее форматирование. Если вы обслуживаете предприятия, вам может понадобиться отдельное поле для ввода пользователем расширения. Если вы пытаетесь поддерживать исходящий процесс вызова, вы можете захотеть сохранить код области и код страны в отдельных столбцах, потому что вы захотите убедиться, что у вас есть специальные окна с часовым поясом для вызова людей в разных кодах областей (создание вызов кому-то в восточном часовом поясе в 10 утра будет намного лучше, чем тот, кто звонит кому-то в часовом поясе Тихого океана, где он находится 7 утра).
  • Пол: Для большого количества приложений вполне разумно хранить гендерный код («M» или «F») в таблице. С другой стороны, есть случаи, когда вам могут понадобиться дополнительные опции (Other, Intersex, Transgendered) или где вам нужно хранить что-то наподобие пола при рождении и текущего пола.
ответил Justin Cave 11 J000000Monday11 2011, 22:17:34
22

Вы можете также угадать на основе выборочных данных и ожидаемой аудитории. Это зависит от вашего местоположения.

Некоторые примечания:

Адрес:

Номер телефона: Международный код, длина, мобильный и дом, разрешить только мобильный номер

ответил gbn 11 J000000Monday11 2011, 22:49:30
9

В дополнение к отличным ответам выше, не забудьте принять символы Unicode. Просто потому, что вы находитесь в США, это не означает, что вы не хотите принимать иностранные символы в свои столбцы.

Тем не менее, я обычно рекомендую 50 символов для имен. 320 должно быть более чем достаточно для адреса электронной почты (вы можете проверить стандарт ANSI, чтобы убедиться). Для ошибки адреса на стороне предупреждения с 255 символами. Хотя вам, вероятно, никогда не понадобится такой большой адрес, вы можете включить, если вы включите линии C /O и тому подобное. Город должен быть довольно большим, есть довольно красивые названия городов. Для государства пойти с детским столом, то же самое со страной. Для почтового индекса не забывайте о международных почтовых кодах, которые больше, чем почтовые индексы США. Просто потому, что вы не поддерживаете международный, вы все еще можете быть. Есть много граждан США, которые живут в разных графствах, включая военных.

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

ответил mrdenny 12 J000000Tuesday11 2011, 00:18:29
8

Моя задница болит от сидения на заборе, поэтому я собираюсь просто выкинуть некоторые ответы и надеяться не спуститься - проголосовать в забвении. Прошу предложить конструктивную критику.

Адрес электронной почты:

мин: 6 ([email protected]). Или 3, если вы хотите отслеживать адреса электронной почты локального домена
max: 320 254 (RFC)

Количество кода для проверки электронной почты на самом деле сумасшедшее, поэтому давайте предположим, что оно действительно, если оно имеет «@»

Вы можете захотеть абстрагировать адрес электронной почты как «метод связи», чтобы вы могли легко перечислить все методы, с которыми можно связаться с пользователем.

Пол

Пол может меняться со временем, поэтому вы можете отслеживать это, если это важно для вас. Следуйте http://en.wikipedia.org/wiki/ISO/IEC_5218

  NOT_KNOWN (0),
Охватываемого (1),
ЖЕНСКИЙ (2),
NOT_APPLICABLE (9);
 

Адреса: NORAM

Я собираюсь взять дешевый выход и придерживаться североамериканских адресов.

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

<сильный> GeographicArea

  id: int
тип: {страна, деление, округ, город, бронирование в Индии}
имя: varchar (45) [1]
аббревиатура: nullable varchar (4)
parent_id: nullable int
 

<сильный> Адрес

  id: int
postal_area_id: int, ссылки GeographicArea
county_or_city_id: int, ссылки GeographicArea
street_address: varchar (255)
suite: nullable varchar (255)
 

Добавьте строку line2 и строку 3, если вам нужно.

См. http://en.wikipedia.org/wiki/Address_(geography)

Теперь адрес - это адрес. Несколько человек могут жить по адресу, а человек может иметь несколько адресов одновременно и со временем, поэтому для этого вам нужно много-много таблиц.

<сильный> PartyAddress

  party_id: int ссылки Party
address_id: int ссылки Адрес
цель: {home, work, ...}
 

Добавьте from_date и nullable to_date , если отслеживание со временем.

Телефонные номера

Сторона может иметь несколько телефонных номеров, а номер телефона может использоваться несколькими людьми. Телефонный номер может использоваться для факсов, телефонных звонков, модемов и т. Д. И может иметь расширения. Все они могут со временем меняться.

<сильный> PhoneNumber

  id: int
Значение: varchar (15) - максимальный допустимый МСЭ
 

Мин может быть 3 (для «911») или, может быть, 7 («310-4NET», который является особым видом локального номера, который не позволяет набирать код зоны)

Вы можете разделить его на код страны и т. д., если это необходимо.

Вы должны использовать http://en.wikipedia.org/wiki/E.164 стандарт

PartyPhoneNumber

  party_id: int ссылки Party
phone_number_id ссылки Номер телефона
extension: nullable varchar (11) - ITU max
цель: {home, work, fax, modem, ...}
 

Имена

Имена жесткие. Вот почему:

  1. У некоторых людей есть юридическое имя с одним словом в нем http: //en.wikipedia .org /вики /List_of_legally_mononymous_people

  2. У некоторых людей есть имена со многими словами http: //en.wikipedia. орг /вики /Wolfe% 2B585, _Senior

  3. У некоторых людей одновременно есть несколько имен (например, в моем университете есть много азиатских студентов, но им нравится использовать «предпочтительные» более вестернизированные имена)

  4. Иногда вам нужно отслеживать имена людей с течением времени, такие как девичья фамилия и фамилии.

  5. Вы хотите отвлечь людей и организации по разным причинам.

    создать таблицу участника (   первичный ключ bigserial id );

    создать таблицу имя_папки (   идентификатор первичного ключа bigserial,   party_id bigint not null ссылки party (id),   type smallint not null ссылки party_name_type (id) --elided, ex "maiden", "legal" );

    создать таблицу name_component (   идентификатор первичного ключа bigserial,   party_name_id bigint not null ссылки имя_пакета (id),   type smallint not null ссылки name_component_type (id), --eled ex "given"   текст имени не равен нулю );

ответил Neil McGuigan 14 J0000006Europe/Moscow 2012, 01:01:42
3

С несколько иной точки зрения, чем предыдущие ответы, и поскольку кажется, что нужно поговорить о LDAP , RFC 4519 - «Протокол доступа к легкому каталогу (LDAP): схема для пользовательских приложений « может представлять интерес.

Может быть полезно, если ваше приложение должно быть сопоставлено с таким каталогом. В противном случае это, вероятно, не соответствует вашим требованиям.

Эти определения - это больше, чем просто данные, а также некоторые операторы, которые можно использовать в полях. postalAddress , например, это caseIgnoreListSubstringsMatch . Я не предлагаю вам строго придерживаться этой схемы, но изучение принципов может быть интересно, в частности, как вам может потребоваться сравнить имя и адреса в вашем приложении, которые могут иметь отношение к дизайну вашей базы данных.

ответил Bruno 14 J000000Thursday11 2011, 02:45:37
3

Что касается имен, рассмотрите возможность использования двойных кавычек, чтобы вам не пришлось избегать апострофов на ирландских или итальянских именах (например, O'Hara или D'Amato).

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

ответил KiloVoltaire 20 Mayam15 2015, 06:43:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132