Создание базы данных контактов - нужно немного вдохновения схемы

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

Я в основном сварил контакт с "сущностью" (личность, компания, роль и т.д.).

Каждый Entity может иметь несколько записей Адрес, Телефон, E-Mail.
- Каждый из них определяет "отношения" (home/work/assistant и т.д.).
- Entity {1} - {relationship} → {0.. *} Данные
Entity может иметь несколько полей, которые являются хранилищем данных произвольной формы для других "общих" данных (дни рождения, учетная запись AIM и т.д.).
- Объект {1} - {fieldName} → {0.. *} Данные поля
Сущность может ссылаться на другую Entity, например, как на сотрудника, супруга
- Entity {0..} < - {relationship} → {0..} Entity

Кто-нибудь выполнил какие-либо SQL-реализации подобных контактных баз данных? Любые идеи/предложения/ловушки, чтобы избежать того, что вы могли бы поделиться с кем-то, кто пытается самостоятельно работать над проектом? Описывает ли я то, что я описал, разумным или сложным?

Один вопрос, скажем, у вас 4 человека, которые все работают в одной компании. Все они имеют один и тот же "рабочий" номер телефона (возможно, с другим расширением). Если число или адрес для "работы" меняются, я хотел бы иметь возможность легко обновлять контакты. Теперь многое из этого сводится к тому, как вы будете использовать базу данных. Я думаю, что это связано с привязкой сотрудника к их соответствующим компаниям, но тогда адрес/номер телефона больше не напрямую связаны с сотрудником. Я как бы дебатирую с тем, чтобы сделать связь между Entity/data многими для многих, позволяя вам прикреплять один и тот же почтовый адрес/номер телефона нескольким людям, а обновление в одном месте может обновлять его во всех местах. Я только что подумал об этом? вытягивает волосы

Ответ 1

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

Я бы посоветовал взглянуть на Object Role Modeling (или это тоже), чтобы определить модель простым английским языком, прежде чем вы на самом деле реализуете какие-либо таблицы. Я использую этот плагин VS: NORMA, который также будет генерировать схему для вас тоже.

Кроме того, здесь есть несколько моделей данных, которые могут вас вдохновить. Это "Управление контактами", но есть и другие, например, раздел "Клиенты"

(Я просто хотел опубликовать изображение..)
_{(источник: databaseanswers.org)}

Ответ 2

Это только поможет с вашим вторым вопросом; где расширение телефона фактически относится к отношениям между лицом и компаниями.

Ответ 3

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

РЕДАКТИРОВАТЬ (апрель 2016 года): похоже, веб-мастер Microsoft нарушил связь. Здесь файл Wayback Machine на странице.

Ответ 4

Несколько моментов, которые имеют тенденцию возникать в моем опыте.

Рассмотрим взаимные отношения. Например, если кто-то определен как сотрудник компании, тогда компания по определению является работодателем этого лица.

Рассматриваете ли вы адреса как сущности сами по себе или как просто свободный текст, связанный с человеком/местом? В некоторых приложениях адрес (физическое здание и т.д.) Является "реальным", и только один может существовать в таблице. (Часто используется правительственный/почтовый идентификатор для него).