Проводя некоторые исследования по картированию отношений один-к-одному, я натолкнулся на некоторые утверждения, которые заставили меня усомниться в некоторых моих решениях по проектированию базы данных.
В основном, у меня есть некоторые сущности, подобные следующим:
Лицо, контакт, родитель
И контакт, и родитель - это люди.
Человек может быть контактом, родителем, обоими или ни тем, ни другим.
В структуре базы данных, которую я придумал, есть таблица для каждой из этих трех сущностей, и все три таблицы имеют общий идентификатор (PersonID). С точки зрения проектирования базы данных это, по-видимому, хорошо нормализованный и достаточно эффективный способ представления базы данных и ее взаимосвязей (по крайней мере, для меня).
С этого момента я начинаю кодировать классы C # и отображения NHibnerate для представления этих объектов. Самый естественный подход к отображению, который я могу найти, - это использовать отображение. Другие параметры (один-к-одному, один-ко-многим и т. Д.), По-видимому, требуют добавления одного или нескольких ненужных FK в таблицы. Просматривая документацию NHibernate, я натыкаюсь на следующее утверждение:
Эта функция часто полезна только для устаревших моделей данных, мы рекомендуем меньше таблиц, чем классов, и модель детализированных доменов. Однако это полезно для переключения между стратегиями отображения наследования в одной иерархии, как будет объяснено ниже.
Мой вопрос:
А) Я нарушаю этот принцип?
Б) Если да, то как мне лучше спроектировать эту систему?
Предполагает ли это утверждение, что я должен объединить все поля Person / Contact / Parent в одну таблицу (со многими обнуляемыми полями)? Или я как-то упускаю суть?
Поскольку это редкий случай, когда я могу создавать таблицы / классы с нуля, я бы хотел, чтобы это было правильно. Заранее спасибо за помощь!
Изменить: Подробнее о том, как я планирую работать с вышеуказанным дизайном базы данных:
Основная идея заключается в том, что каждый человек получает запись в таблице персон. Наличие / отсутствие записей в связанных таблицах определяет, является ли человек родителем, контактом и т. Д. Это, по-видимому, обеспечивает соблюдение отношений one-> one и позволяет выполнять быстрые запросы / объединения (общий первичный идентификатор будет кластерный ПК в каждой таблице).
Редактировать: Спасибо за помощь, ребята. На самом деле, я не очень хорошо разбирался в вопрососпособности запросов, когда разрабатывал эту систему, поэтому собираюсь перейти к чему-то похожему на решения, предложенные Jamie Ide & hlgem. Я нашел все ответы полезными. В целом, похоже, что общие первичные ключи приводят к некоторым проблемам с объектной моделью на стороне c #.