Дизайн базы данных адресной книги: денормализовать?
Я разрабатываю приложение, похожее на менеджер контактов / адресную книгу, но не могу определиться с дизайном базы данных.
В моей текущей настройке у меня есть контакт, который имеет адреса, телефоны, электронные письма и организации. Все свойства контактов в настоящее время являются отдельными таблицами с фк к таблице контактов. Излишне говорить, что контакт может иметь любое количество этих свойств.
Теперь я обнаруживаю, что присоединяюсь ко всем этим таблицам, если хочу прочитать контакты в приложении. Поскольку никакие фильтры, обратный поиск, сортировки и т. Д. Не выполняются для связанных таблиц, не является ли лучшим / более простым решением просто сохранять связанные поля в виде закодированных в json списков в прямых свойствах таблицы контактов?
Например, вместо контакта с fk в таблицу номеров телефонов с 3 записями, просто закодировать все номера телефонов и сохранить их в поле таблицы контактов?
Любые идеи действительно ценятся! (Кстати, я использую Django, хотя это не имеет значения)
3 ответа
Можете ли вы гарантировать, что ваше приложение никогда не будет нуждаться в этих других функциях? Вы действительно хотите нарисовать себя в углу так, что вы не можете легко поддержать все это позже?
Как правило, денормализация происходит только по соображениям эффективности. И затем копия нормализованных данных все еще сохраняется для оперативной работы, а денормализованные данные используются для автономной обработки, где статический снимок вполне подходит.
Привыкайте к написанию объединений. Так работает SQL. Необходимость сделать это не означает, что что-то не так.
Я знаю, что я опоздал, но для тех, у кого такая же проблема.
ИМО, в этом случае моделирование метаданных - путь. http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map
Похоже, вы предлагаете взять данные, которые в настоящее время смоделированы как пять таблиц SQL, и преобразовать их в общий многозначный тип (у вашего продукта SQL есть хорошая поддержка для этого?). Единственный способ, которым я могу видеть это, представляет собой "денормализацию", если вы предлагали нарушить 1NF, после чего вы можете отказаться от SQL как хранилища данных, потому что ваши данные больше не будут реляционными! В противном случае ваши данные все равно будут нормализованы, но вы потеряете возможность запрашивать его атрибуты с помощью SQL (если только у вашего продукта SQL нет расширений для запроса многозначных атрибутов). Решающим фактором, по-видимому, является: нужно ли запрашивать эти атрибуты с помощью SQL?