Разработка таблиц для различных типов контактов

Question

Сегодня я получил три источника контактов в моей системе:

• Пользователи системы
• Адресная книга
• Система CRM

Они хранятся в разных таблицах. Я переключаюсь на nhibernate из собственного решения ORM, и nhibernate получил отличную поддержку наследования. Поэтому я рассматриваю следующее:

1. Создать базовую таблицу со всеми общими полями
2. Создание одной таблицы для каждого типа контакта (система, адресная книга, crm) с конкретными полями + ссылка на строку базовой таблицы (base_user_id или аналогичная). адресная книга, crm).

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

Это облегчит добавление других источников и синхронизацию всего.

Мой вопрос: вы видите какие-либо проблемы с таким решением?

Answer 1

Использование одной таблицы на иерархию проще, но дает 2 возможности:

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

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

Answer 2

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

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

Почему бы просто не создать классы, отражающие дизайн, который эффективен как есть?