Как хранить редактируемые копии исходных данных в реляционной базе данных?

#sql #database-design #relational-database

Вопрос:

Давайте предположим, что у меня есть две сущности: Компания и Заказ.

Компания:

 Id
Name
Phone
 

Заказ:

 Id
CompanyId
Name
TotalAmount
 

Я упростил эти сущности, в реальном проекте они намного больше.

В моем приложении у меня есть представление компаний, в котором я могу выполнять основные операции CRUD. То же самое касается Заказов.

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

У меня есть 2 решения:

Первое решение: Создайте отдельную таблицу OrderCompany, в которой я могу хранить копии данных компаний для каждого заказа. В этом случае я могу отредактировать копию, и это не повлияет на исходную компанию, но у меня есть сомнения, потому что это будет полная копия таблицы контактов только с одним дополнительным полем — OrderID.

Второе решение: Сохраните копии компаний непосредственно в таблице Компаний и добавьте идентификатор заказа в эту таблицу. Исходные компании будут храниться с идентификатором заказа = null, для копий будет присвоен идентификатор заказа. В этом случае у меня нет 2 почти одинаковых таблиц, как в первом решении, но я не уверен, что хранение оригиналов и копий в одной таблице-хорошая идея.

Какое из этих двух решений, на ваш взгляд, лучше? Может быть, есть лучший способ?

Ответ №1:

Я подозреваю, что вы путаете некоторые разные понятия. «Компания» не должна меняться. Однако у компаний может быть что-то-скажем, «контакты» — что действительно меняется.

Итак, я думаю, вам нужна модель, в которой у вас есть:

  • companies , в котором содержится основная информация о компаниях, например, companyid название компании и так далее. Эта информация не меняется (или, по крайней мере, не для каждого заказа). У компании также будет «контакт»по умолчанию.
  • companyContacts , что было бы для контакта в компании. Это будет иметь companyId , а затем дополнительную информацию. Для разных заказов могут использоваться разные контакты.
  • orders который имел бы companyContactId .

Затем заказ будет передан компании и конкретному контакту внутри компании. При необходимости может быть создана новая контактная информация.

Комментарии:

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

2. @GlebSkripnikov . . . Я предлагаю, чтобы ваша модель данных была неполной.

Ответ №2:

Я полагаю, что мы можем пойти с вашим 1-м подходом, так как любое изменение в таблице компаний не будет стоить никаких изменений в таблице OrderCompany.