Дизайн базы данных адресной книги: денормализовать?

Question

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

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

Теперь я обнаруживаю, что присоединяюсь ко всем этим таблицам вместе, если хочу прочитать контакты в приложении.Поскольку никакие фильтры, обратный поиск, сортировки и т. Д. Не выполняются для связанных таблиц, не является ли лучшим / более простым решением просто сохранить связанные поля в виде закодированных в json списков в прямых свойствах таблицы контактов?* Например, вместо Контакта с таблицей телефонных номеров с 3 записями, просто закодируйте все номера телефонов и сохраните их в поле таблицы Контактов?

Любые идеи действительно приветствуются!(Кстати, я использую Django, хотя это не имеет значения)

Answer 1

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

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

Привыкайте писать объединения.Так работает SQL.Необходимость сделать это не означает, что что-то не так.

Answer 2

Похоже, вы предлагаете взять данные, которые в настоящее время смоделированы как пять таблиц SQL, и преобразовать их в общий многозначный тип (есть ли у вашего продукта SQL хорошая поддержка для этого?)Если вы предлагаете нарушить 1NF , тогда вы можете также отказаться от SQL как хранилища данных, поскольку ваши данные больше не будут реляционными!В противном случае ваши данные все равно будут нормализованы, но вы потеряете возможность запрашивать его атрибуты с помощью SQL (если только у вашего продукта SQL нет расширений для запроса многозначных атрибутов).Кажется, решающим фактором является: нужно ли запрашивать эти атрибуты с помощью SQL?

Answer 3

Я знаю, что опоздал, но для тех, у кого такая же проблема.

ИМО, в этом случае лучше всего использовать моделирование метаданных.http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map