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

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

2 голосов
/ 02 сентября 2008

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

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

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

Ответы [ 7 ]

7 голосов
/ 14 сентября 2008

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

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

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

Первичный ключ (однозначно идентифицирующий каждую строку) People - pid. PK AddressBook представляет собой композицию pid и tag (pid, tag).

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

Люди

1, Kirk

2, Spock

AddressBook

1, home, '123 Main Street', Iowa

1, work, 'USS Enterprise NCC-1701'

2, other, 'Mt. Selaya, Vulcan'

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

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

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

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

3 голосов
/ 16 ноября 2008

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

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

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

Приветствия, -D.

3 голосов
/ 02 сентября 2008

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

1 голос
/ 02 сентября 2008

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

1 голос
/ 02 сентября 2008

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

0 голосов
/ 03 июля 2012

У меня нет сценария, но у меня есть 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, но я надеюсь, что это поможет.

0 голосов
/ 02 сентября 2008

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

...