Каковы наиболее распространенные рекомендации по длине и типу данных в общих полях, например:
- Имя
- Фамилия
- Адрес
- Эл. адрес
- секс
- государственный
- город
- Страна
- Номер телефона
так далее....
Каковы наиболее распространенные рекомендации по длине и типу данных в общих полях, например:
так далее....
Ответы:
Я склонен быть очень подозрительным к любому набору универсальных лучших практик, потому что для большинства из этих областей дьявол кроется в деталях. Тот факт, что информация относительно распространена, не означает, что ваше приложение использует данные точно так же, как другие приложения. Это означает, что ваша модель данных может немного отличаться.
STATE
таблицу и создать связь между внешним ключом STATE
и ADDRESS
таблицами. Но способность идентифицировать действительные значения подразумевает, что вы ограничиваете набор допустимых адресов, по крайней мере, для определенного набора стран. Это хорошо для многих сайтов, но тогда вам нужно немного поработать, чтобы поддержать новую страну.CITY
таблица с действующими городами и внешним ключом отношением между CITY
и ADDRESS
таблицами. С другой стороны, если вы просто пытаетесь доставить товар, и вам не очень важно, есть ли в вашей таблице разные версии одного и того же города, достаточно предоставить пользователю произвольную форму ввода текста. Конечно, если вы храните внешние ключи, у вас будет много работы, чтобы убедиться, что у вас есть все допустимые значения. Но есть продукты, в которых весь смысл в том, что компания уже выполнила эту работу (например, базы данных по налогу с продаж).Вы также можете догадаться на основе выборки данных и ожидаемой аудитории. Это зависит от вашего местоположения.
Некоторые заметки:
Адреса:
Имена:
Номер телефона: международный код, длина, мобильный телефон против дома, разрешить мобильный как только номер
В дополнение к отличным ответам выше, не забывайте принимать символы Юникода. То, что вы находитесь в США, не означает, что вы не хотите принимать иностранные символы в свои столбцы.
Тем не менее, я обычно рекомендую 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, ...}
Имена жесткие. Вот почему:
У некоторых людей есть официальное имя с одним словом http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
У некоторых людей есть имена со многими словами http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
У некоторых людей есть несколько имен одновременно (например, в моем университете много азиатских студентов, но им нравится использовать «предпочтительные» более вестернизированные имена)
Иногда вам нужно отслеживать имена людей с течением времени, например, девичьи имена и фамилии.
Вы хотите абстрагировать людей и организации по разным причинам
создать табличную вечеринку (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 и т. Д.).