Схема БД адресной книги

Question

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

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

Я использую SQL Server 2005, если это имеет значение.

Answer 1

Рассмотрим две таблицы для людей и их адреса:

People (pid, prefix, firstName, lastName, suffix, DOB, ... primaryAddressTag )

AddressBook (pid, tag, address1, address2, city, stateProv, postalCode, ... )

Первичный ключ (который однозначно определяет каждую строку) людей pid, PK AddressBook - это составление pid и тега. (pid, tag),

Некоторые примеры данных:

люди

1, Kirk

2, Spock

Адресная книга

1, home, '123 Main Street', Iowa

1, work, 'USS Enterprise NCC-1701'

2, other, 'Mt. Selaya, Vulcan'

В этом примере Кирк имеет два адреса: один "домашний" и один "рабочий". Один из этих двух можно (и нужно) отметить как внешний ключ (например, перекрестную ссылку) в People в столбце primaryAddressTag.

Спок имеет единственный адрес с тегом "прочее". Так как это единственный адрес Спока, значение "другие" должно идти в primaryAddressTag столбец для pid=2.

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

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

Answer 2

Не бойтесь нормализовать ваши данные. Нормализация, как упоминает Джон, является решением, а не проблемой. Если вы попытаетесь денормализовать ваши данные только для того, чтобы избежать пары соединений, то в будущем у вас будут серьезные проблемы. Попытка провести рефакторинг данных такого рода после получения набора данных разумного размера НЕ БУДЕТ УДОВОЛЬСТВОВАТЬ.

Я настоятельно рекомендую вам проверить Highrise из 36 сигналов. Это было недавно рекомендовано мне, когда я искал менеджера контактов онлайн. Это так много правильно. На самом деле, мое единственное возражение по поводу сервиса в том, что я считаю, что платные версии слишком дороги - и все.

В нынешних условиях я не вписываюсь в единый адресный профиль. У меня есть 4-5 адресов электронной почты, которые я регулярно использую, 5 телефонных номеров, 3 адреса, несколько веб-сайтов и профили мгновенных сообщений, которые я бы включил в свой контактный профиль. Если вы сейчас начинаете создавать систему управления контактами и не обременены архитектурными ограничениями (представьте, что контакты gmail могут быть привязаны к одному адресу электронной почты), тогда сделайте одолжение своим пользователям и сделайте свою структуру контактов настолько гибкой (нормализованной), насколько это возможно. возможный.

Ура, -D.

Answer 3

Зачем полная нормализация "быть беспорядком"? Это именно то, что нормализация делает менее грязным.

Answer 4

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

Answer 5

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

Answer 6

У меня нет сценария, но у меня есть mySQL, который вы можете использовать. До этого я должен был упомянуть, что существуют два логических подхода к хранению vCards в SQL:

1. Сохраните всю карту и позвольте базе данных искать, (возможно) огромные текстовые строки, и обрабатывать их в другой части вашего кода или даже на стороне клиента. например

   СОЗДАЙТЕ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ vcards (
   name_or_letter varchar (250) NOT NULL,
   vcard текст НЕ НУЛЬ,
   timestamp отметка времени по умолчанию CURRENT_TIMESTAMP при обновлении CURRENT_TIMESTAMP,
   ОСНОВНОЙ КЛЮЧ (username)
   ) ENGINE = MySAM CHARSET ПО УМОЛЧАНИЮ =utf8 COLLATE=utf8_bin;

Вероятно, это легко реализовать (в зависимости от того, что вы делаете с данными), хотя ваш поиск будет медленным, если у вас много записей. Если это только для вас, тогда это может сработать ((если это хорошо, тогда это не только для вас). Затем вы можете обработать клиентскую или серверную сторону vCard, используя какой-то прекрасный модуль, которым вы делитесь (или кто-то другой поделился) с тобой.)

Я наблюдал, как развивается vCard, и знаю, что в будущем произойдут некоторые изменения, поэтому я использую три таблицы.

Первая - это карта (в основном это ссылки на мои существующие таблицы - если вам это не нужно, то ваша версия может быть урезанной). Второе - это определения карт (которые в vCard говорят как профиль). Последний - все фактические данные для карт.

Поскольку я позволил DBIx::Class (да, я один из них), чтобы все базы данных работали так, (три таблицы), кажется, работают довольно хорошо для меня (хотя, очевидно, вы можете сжать типы, чтобы соответствовать rfc2426 больше близко, но по большей части каждый кусок данных является просто текстовой строкой.)

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

 CREATE TABLE `vCards` (   
 `card_id` int(255) unsigned NOT NULL AUTO_INCREMENT,   
 `card_peid` int(255) DEFAULT NULL COMMENT 'link back to user table',   
 `card_acid` int(255) DEFAULT NULL COMMENT 'link back to account table',      
 `card_language` varchar(5) DEFAULT NULL COMMENT 'en en_GB',
 `card_encoding` varchar(32) DEFAULT 'UTF-8' COMMENT 'why use anything else?',
 `card_created` datetime NOT NULL,  
 `card_updated` datetime NOT NULL,
 PRIMARY KEY (`card_id`) )
 ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='These are the contact cards'

   create table vCard_profile (
    vcprofile_id int(255) unsigned auto_increment NOT NULL,
    vcprofile_version enum('rfc2426') DEFAULT "rfc2426" COMMENT "defaults to vCard 3.0",
    vcprofile_feature char(16) COMMENT "FN to CATEGORIES",
    vcprofile_type enum('text','bin') DEFAULT "text" COMMENT "if it is too large for vcd_value then user vcd_bin",
  PRIMARY KEY (`vcprofile_id`)
) COMMENT "These are the valid types of card entry";
INSERT INTO vCard_profile VALUES('','rfc2426','FN','text'),('','rfc2426','N','text'),('','rfc2426','NICKNAME','text'),('','rfc2426','PHOTO','bin'),('','rfc2426','BDAY','text'),('','rfc2426','ADR','text'),('','rfc2426','LABEL','text'),('','rfc2426','TEL','text'),('','rfc2426','EMAIL','text'),('','rfc2426','MAILER','text'),('','rfc2426','TZ','text'),('','rfc2426','GEO','text'),('','rfc2426','TITLE','text'),('','rfc2426','ROLE','text'),('','rfc2426','LOGO','bin'),('','rfc2426','AGENT','text'),('','rfc2426','ORG','text'),('','rfc2426','CATEGORIES','text'),('','rfc2426','NOTE','text'),('','rfc2426','PRODID','text'),('','rfc2426','REV','text'),('','rfc2426','SORT-STRING','text'),('','rfc2426','SOUND','bin'),('','rfc2426','UID','text'),('','rfc2426','URL','text'),('','rfc2426','VERSION','text'),('','rfc2426','CLASS','text'),('','rfc2426','KEY','bin');

create table vCard_data (
    vcd_id int(255) unsigned auto_increment NOT NULL,
    vcd_card_id int(255) NOT NULL,
    vcd_profile_id int(255) NOT NULL,
    vcd_prof_detail varchar(255) COMMENT "work,home,preferred,order for e.g. multiple email addresses",
    vcd_value varchar(255),
    vcd_bin blob COMMENT "for when varchar(255) is too small",
    PRIMARY KEY (`vcd_id`)
) COMMENT "The actual vCard data";

Это не лучший SQL, но я надеюсь, что это поможет.

Answer 7

Если вы предполагаете, что у каждого пользователя есть один или несколько адресов, номер телефона и т. Д., У вас может быть таблица "Пользователи", "Таблица адресов" (содержащая первичный ключ и затем неуникальная ссылка на пользователей), то же самое для телефонные номера - разрешение нескольких строк с одним и тем же внешним ключом UserID, что сделает запрос "все адреса для пользователя X" довольно простым.