Які найпоширеніші найкращі практики щодо довжини та типу даних у загальних полях:
тощо.
Відповіді:
Я схильний би дуже підозріло ставитися до будь-якого набору найкращих універсальних практик, оскільки для більшості цих полів диявол знаходиться в деталях. Тільки тому, що інформація є відносно поширеною, не означає, що ваш додаток використовує дані точно так само, як і інші програми. Це означає, що ваша модель даних може бути дещо іншою.
STATEтаблицю та створити зв'язок із зовнішнім ключем між таблицями STATEта ADDRESS. Але можливість ідентифікувати дійсні значення означає, що ви обмежуєте набір дійсних адрес принаймні певним набором країн. Це добре для багатьох сайтів, але тоді вам доведеться трохи попрацювати, щоб підтримати нову країну.CITYтаблиці з дійсними містами та зовнішньополітичним зв’язком між таблицями CITYта ADDRESS. З іншого боку, якщо ви просто намагаєтесь доставити товар і вам не надто хвилюється, чи є у вас різні версії того самого міста у вашій таблиці, дозволити користувачеві у вільній формі ввести текст достатньо. Звичайно, якщо ви зберігаєте сторонні ключі, вам доведеться виконати досить багато роботи, щоб переконатися, що у вас є всі дійсні значення. Але є продукти, де вся суть у тому, що компанія вже виконала цю роботу (тобто бази даних податку з продажу).Ви також можете здогадатися на основі вибіркових даних та очікуваної аудиторії. Це залежить від вашого місцезнаходження.
Деякі примітки:
Адреси:
Імена:
Номер телефону: міжнародний код, довжина, мобільний та домовий, дозволити мобільному лише номер
На додаток до чудових відповідей вище, не забудьте прийняти символи unicode. Тільки тому, що ви перебуваєте в США, не означає, що ви не хочете приймати іноземних символів у свої стовпці.
Однак, для імен я зазвичай рекомендую 50 символів. 320 має бути більш ніж достатньо для електронної адреси (ви можете перевірити стандарт ANSI). Для помилки адреси на стороні обережності з 255 символами. Хоча вам, мабуть, ніколи не потрібна така велика адреса, можливо, якщо ви включите рядки C / O та подібні речі. Місто має бути досить великим, там є деякі досить довгі назви міст. Для держави йдіть з дитячим столом, так само з країною. Для поштового індексу не забувайте про міжнародні поштові індекси, які довші за поштові індекси США. Просто тому, що ти не підтримуєш міжнародний, ти все ще можеш бути. Є багато громадян США, які живуть в різних округах, включаючи військових.
Не забувайте, що держава повинна бути необов'язковою, оскільки у багатьох країнах немає держав.
Мій бамжа болить від сидіння на паркані, тому я збираюся просто викинути кілька відповідей і сподіваюсь не зійти з голосу в небуття. Прошу запропонувати конструктивну критику.
хв: 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);Я візьму дешевий вихід і дотримуюся північноамериканських адрес.
Зручно абстрагувати країни, відділи, міста та повіти, в основному завдяки оподаткуванню. Податки можуть застосовуватися на багатьох рівнях, тому, якщо ви можете вказати ставку податку на абстрактну географічну область, ви золоті.
GeographicArea :
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 первинний ключ);
створити таблицю party_name (id bigserial первинний ключ, party_id bigint not null reference party (id), введіть smallint не null посилання party_name_type (id) --elided, ex "maiden", "legal");
створити ім'я таблиці_компонента (id bigserial первинний ключ, party_name_id bigint не нульові посилання party_name (id), введіть smallint not null посилання name_component_type (id), --elided ex "заданий" текст імені не null);
З дещо іншого погляду, ніж попередні відповіді, і оскільки, здається, добре говорити про LDAP , RFC 4519 - "Легкий протокол доступу до каталогів (LDAP): схема для користувацьких додатків" може представляти інтерес.
Це може бути корисно, якщо вашу програму потрібно буде відобразити в такому каталозі. Інакше він, мабуть, не адаптований до ваших вимог.
Ці визначення більше стосуються не лише даних, але й деяких операторів, які можна використовувати в полях. postalAddress, наприклад, a caseIgnoreListSubstringsMatch. Я не пропоную суворо дотримуватися цієї схеми, але погляд на принципи може бути цікавим, зокрема, яким чином вам доведеться порівнювати ім’я та адреси у вашій програмі, можливо, це стосується дизайну вашої бази даних.
Щодо імен, подумайте про використання подвійних лапок, щоб вам не довелося уникати апостроф в ірландських чи італійських іменах (наприклад, О'Хара або Д'Амато).
Я також рекомендую отримати хороший набір регулярних виразів для використання, щоб ви могли виводити частини ваших іменних полів (наприклад, перший початковий, псевдонім, Jr / Sr тощо).