Разработка БД для нескольких типов объектов

Question

Мне нужно разработать приложение, в котором будет 4 типа пользовательских объектов (администраторы, партнеры, компании и клиенты), каждый тип пользователя имеет свой собственный набор деталей, и все они должны иметь возможность выполнять общие операции, такие как отправка сообщений , делать платежи и так далее. Эти операции должны храниться в одной таблице, но они должны ссылаться на конкретного пользователя, несмотря на его тип.

Какой дизайн базы данных будет более подходящим?

Answer 1

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

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

Answer 2

"Я просто хотел бы добавить еще одну вещь, вы предлагаете, чтобы у меня была таблица для каждого типа пользователя ... Я предпочитаю такой подход, однако, как бы я разработал схему, в которой я могу сказать, что отправил идентификатор пользователя 7 (admin) сообщение для пользователя с идентификатором 537 (клиент)? Или, что пользователь с идентификатором 70 (компания) получил платеж? "

Ничто не мешает вам сделать это. Иметь таблицу {сообщение получателя отправителя (-id)} с первичным ключом, всеми тремя атрибутами и двумя FK {отправителем} и {получателем}. FK ссылаются на первичный ключ таблицы, которая содержит атрибуты COMMON всех пользователей.

Теперь ваш следующий вопрос может звучать так: «но я хочу, чтобы правило гласило, что ни один пользователь типа X не может напрямую отправить сообщение любому пользователю типа Y».

Это точка, в которой любая текущая РЕАЛИЗАЦИЯ (так называемой) реляционной СУБД показывает свои слабые стороны. Даже Oracle или DB2 не могут сделать это декларативно . Мне просто слишком много нужно сказать об этом предмете, чтобы вписаться в этот ответ.

Кстати, вы, похоже, проявили интерес к моему ответу, несмотря на все отрицательные отзывы. Очень ценю это.

Answer 3

Посмотрите на три способа сделать это в шаблонах архитектуры корпоративных приложений:

http://martinfowler.com/eaaCatalog/singleTableInheritance.html

http://martinfowler.com/eaaCatalog/classTableInheritance.html

http://martinfowler.com/eaaCatalog/concreteTableInheritance.html

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

Answer 4

user
================
id
user_type_id
name
etc

user_type
================
id
name (admin, partner...)
etc

user_detail
================
id
user_id
user_detail_type_id
value

user_detail_type
================
id
name

user_type_to_user_detail_type
================
id
user_type_id
user_detail_type_id
(maps which user types have which detail types)