Как мне смоделировать групповое отношение в базе данных и в ООП?

Question

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

Как мне смоделировать это в базе данных?Как мне смоделировать это в моих классах, ООП?Я вижу несколько разных решений, но все они сложны в некотором роде, поэтому я не знаю, как это реализовать.

Либо я мог бы пойти с тремя таблицами, Item ItemGroup GroupRelationи держите отметку времени на GroupRelation.Если информация об элементе обновляется, мне нужно создать новый элемент и новое GroupRelation.Если Элемент меняет группу, мне нужно создать новое GroupRelation.И если информация о Группе изменяется, я должен создать новую Группу и новое GroupRelation.Это сложно, так как я должен создать несколько новых объектов при изменении.

Item
+----+---------+-----+------+
| id | item_nr | ean | name |
+----+---------+-----+------+

ItemGroup
+----+------------+-----+
| id | group_name | vat |
+----+------------+-----+

GroupRelation
+----+---------+----------+-----------+
| id | item_id | group_id | timestamp |
+----+---------+----------+-----------+

Альтернативное решение может состоять в том, чтобы иметь только два класса Item и ItemGroup, но тогда мне нужно иметь временную метку в обоихиз них, так что я знаю, когда они меняются.Если группа обновляется, мне нужно обновить все элементы, принадлежащие этой группе, так что это также сложно.

Item
+----+---------+-----+------+----------+-----------+
| id | item_nr | ean | name | group_id | timestamp |
+----+---------+-----+------+----------+-----------+

ItemGroup
+----+------------+-----+-----------+
| id | group_name | vat | timestamp |
+----+------------+-----+-----------+

И, возможно, есть другие решения, возможно, стоит переместить старые версии в другую таблицу.Но тогда сложно искать данные, когда нужно искать как текущие, так и старые данные.Или у меня может быть столбец prev_id, который ссылается на старую версию.

Есть ли кто-нибудь, кто имеет опыт подобных моделей данных и имеет какие-либо рекомендации?Есть ли лучшие практики для такого рода проблем?

Answer 1

Я бы использовал ваши Item, ItemGroup и GroupRelation в качестве хорошего нормализованного проекта с минимальным дублированием.

Ваши требования к аудиту можно смоделировать с помощью дополнительной таблицы для каждой таблицы, которая вам нужна.Аудит (например: ItemAudit, ItemGroupAudit), который содержит поля, которые необходимо проверить, и временную метку.Вы заполняете таблицу аудита каждый раз, когда изменяется поле, подлежащее аудиту.

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

Answer 2

Из вашего описания я думаю, что есть концепция GroupRelationHistory, которая существует неявно в вашей модели. Я бы сделал это для собственной сущности, такой как Item, ItemGroup и GroupRelation.

В объектном мире я бы заставил Item знать о его GroupRelationHistory, что означает, что объект Item имеет ссылку на GroupRelationHistory объект. По сути GroupRelationHistory - это просто список из нуля, одного или нескольких GroupRelation с.

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