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

Question

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

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

Либо я мог бы пойти с тремя столами, ItemItemGroupGroupRelation и сохранить отметку времени на 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 s.

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