Мне нужна помощь в разработке моей базы данных oo, чтобы обрабатывать несколько видов отношений

Question

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

Я рассмотрел только жесткое кодирование каждого действия.я также рассмотрел обобщение типов действий на подклассы, такие как активность на основе посещаемости и активность на основе покупки, но это ограничивает расширяемость системы.и я должен рассмотреть классы объектов, а также.придется сделать 40 разных классов, которые все расширяют активность?я также подумал о создании таблицы Activity_type, но я не знаю, как бы я реализовал типы активности в Java-части.

мой вопрос: как мне проектировать мою систему?

Answer 1

Возможно, вы захотите прочитать о модели атрибут-значение-сущности .

Answer 2

Доступен шаблон. Взгляните на на этот вопрос / ответ ; описывает схему наблюдения. Он использует пять таблиц и может быть реализован в «стандартной» РСУБД. Сущность может иметь любое количество пользовательских свойств (наблюдений).

Answer 3

Рассмотрим эту модель

Type-of-Activity 1 <----> * Type-of-Things-Needed
  1                           1
  |                           |
  *                           *
Activity         1 <----> * Things-Needed

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

Answer 4

Вот одна точка зрения жесткого кодирования действий против их сохранения в базе данных :

Если вы жестко закодировали действия в своем коде, вы не можете добавлять (или удалять)или изменить) действие без перекомпиляции и повторного развертывания вашего кода.Но во время кодирования вы знаете все возможные действия, поэтому ваш код может обрабатывать их все.

Если вы сохраняете действия в базе данных, вы можете легко добавлять, удалять или изменять действия.И вы можете позволить пользователям (возможно, только пользователям с определенными ролями) вносить изменения в действия.Но ваш код может не обязательно правильно обрабатывать новое действие.

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

Answer 5

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

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

Answer 6

Вам нужно искать / сортировать, используя все эти дополнительные свойства, то есть они должны быть полями SQL? Если нет, вы можете иметь свои основные свойства в виде индексированных полей, а другие поля в BLOB-объекте (например, XML-документе), который хранится в одном поле каждой таблицы SQL.