Лучшие практики в общих областях (имя, адрес электронной почты, адрес, пол и т. Д.)

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

• Имя
• Фамилия
• Адрес
• Эл. адрес
• секс
• государственный
• город
• Страна
• Номер телефона

так далее....

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

• Имя и фамилия: почему вы захватываете имя? Если у вас есть требование записать полное юридическое имя человека (то есть вы готовите юридические документы или свидетельства о рождении), вы, вероятно, захотите предоставить больше места для ввода текста, чем если бы вы просто запрашивали имя человека, чтобы вы есть что позвонить им в вашем новом веб-приложении.
• Адрес: Что вы собираетесь делать с адресом? Какие адреса вы храните? Если вы храните адрес недвижимости в Соединенных Штатах, на которую вы закладываете закладную, вы, скорее всего, очень заботитесь о получении полностью стандартизированного адреса, и в этом случае модель данных, возможно, захочет очень точно указать любой ваш адрес. инструмент стандартизации возвращается. Если вы просто хотите, чтобы люди могли вводить адрес для доставки продукта, возможно, достаточно пары строк для произвольного текста. Длина строк там может зависеть от требований последующих процессов, которые делают такие вещи, как печать адресных меток.
• Состояние. Предполагая, что вы можете определить допустимые значения состояния, возможно, имеет смысл создать STATEтаблицу и создать связь между внешним ключом STATEи ADDRESSтаблицами. Но способность идентифицировать действительные значения подразумевает, что вы ограничиваете набор допустимых адресов, по крайней мере, для определенного набора стран. Это хорошо для многих сайтов, но тогда вам нужно немного поработать, чтобы поддержать новую страну.
• Город: если вы имеете дело с данными, в отношении которых существуют потенциально действующие правила на уровне города (т. Е. Когда существуют различные виды налоговых ставок, применяемых в зависимости от города), вы можете рассматривать их так же, как штат, и иметь CITYтаблица с действующими городами и внешним ключом отношением между CITYи ADDRESSтаблицами. С другой стороны, если вы просто пытаетесь доставить товар, и вам не очень важно, есть ли в вашей таблице разные версии одного и того же города, достаточно предоставить пользователю произвольную форму ввода текста. Конечно, если вы храните внешние ключи, у вас будет много работы, чтобы убедиться, что у вас есть все допустимые значения. Но есть продукты, в которых весь смысл в том, что компания уже выполнила эту работу (например, базы данных по налогу с продаж).
• Телефон: Что вы делаете с номерами телефонов и почему? Некоторые приложения захотят принимать телефонные номера в любом формате, который пользователь решит ввести, и сохранить это форматирование для всех последующих запросов. Это было бы обычным делом, если вы разрабатываете личную адресную книгу, где у пользователей есть свои предпочтения относительно того, как телефонные номера хранятся и отображаются. Другие приложения могут игнорировать введенное форматирование, извлекать только числовые символы, а затем форматировать данные при извлечении, чтобы все номера телефонов имели одинаковое форматирование. Если вы работаете с предприятиями, вам может потребоваться отдельное поле для ввода добавочного номера. Если вы пытаетесь поддержать процесс исходящих вызовов, вы можете сохранить код города и код страны в отдельных столбцах, поскольку вы
• Пол: Для очень многих приложений вполне разумно хранить гендерный код («M» или «F») в таблице. С другой стороны, бывают случаи, когда вам могут потребоваться дополнительные параметры («Другой», «Интерсекс», «Трансгендерный») или когда вам необходимо сохранить что-то вроде пола при рождении и текущего пола.

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

Некоторые заметки:

Адреса:

• У меня нет штата, и меня раздражает, когда я выбираю "За пределами США"
• Почтовые округа Великобритании не имеют сходства с регионами местного самоуправления: см. «Тип и размер столбца для международных страновых подразделений (штатов, провинций, территорий и т. Д.)» В SO, где я нарушил чьи-то предположения

Имена:

• Не забудьте фамилию, имя, отчество, имя племени, отчество и т. Д.
• Посмотрите «Программисты лжи верят в имена», а затем подумайте о том, чтобы плакать
• Смотрите «Фамилия Имя» и просто плачьте
• SO "Какое самое длинное человеческое имя вы можете ожидать?" для работающего примера

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

В дополнение к отличным ответам выше, не забывайте принимать символы Юникода. То, что вы находитесь в США, не означает, что вы не хотите принимать иностранные символы в свои столбцы.

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

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

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

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

мин: 6 (a@g.cn). Или 3, если вы хотите отслеживать адреса электронной почты локального домена,
максимум: 320 254 (RFC)

Объем кода для проверки электронной почты на самом деле безумен, поэтому давайте просто предположим, что он действителен, если у него есть «@»

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

Пол

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

NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);

Адреса: НОРАМ

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

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

Географическая зона :

id: int  
type: {country, division, county, city, indian reservation}  
name: varchar(45)  [1]
abbreviation: nullable varchar(4)  
parent_id: nullable int  

Адрес :

id: int  
postal_area_id: int, references GeographicArea  
county_or_city_id: int, references GeographicArea  
street_address: varchar(255)  
suite: nullable varchar(255)  

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

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

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

PartyAddress

party_id: int references Party  
address_id: int references Address  
purpose: {home, work, ...}  

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

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

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

Номер телефона

id: int  
value: varchar(15) - the max allowed by the ITU  

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

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

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

PartyPhoneNumber

party_id: int references Party  
phone_number_id references PhoneNumber  
extension: nullable varchar(11) - ITU max  
purpose: {home, work, fax, modem, ...}  

имена

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

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

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

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

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

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

   создать табличную вечеринку (id bigserial primary key);

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

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

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

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

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

Что касается имен, рассмотрите возможность использования двойных кавычек, чтобы избежать апострофов в ирландских или итальянских именах (например, О'Хара или Д'Амато).

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