Целостность связанных объектов данных при обновлении

Question

Какова наилучшая практика для поддержания целостности связанных объектов данных при обновлении?

Мой сценарий

1. У меня есть две сущности "Клиент и Счет-фактура ". [Клиент является определением и Счет-фактура является транзакцией].
2. После выставления многих счетов клиент бывает, что клиент информация должна быть изменена например «его платежный адрес / местоположение изменилось или название компании ... и т. д. ".
3. Это нормально, что пользователи должны быть возможность обновления клиента информация, чтобы сохранить целостность данные в системе.
4. В инвойсе "Транзакция субъекта" Я не храню только идентификатор клиента, но также вся информация о клиенте, связанная с счет-фактура типа «имя клиента, адрес, контакт ", и это хорошо известно подход для хранения данных в объекты транзакции.
5. Если пользователь создал новый счет, Информация о новом клиенте будет хранится в записи счета-фактуры вместе с тем же идентификатором клиента (очень очевидно!).

Мои вопросы

1. Можно ли связывать объекты данных «клиенты» из разных мест для вставки и обновления? [Объяснение: если я следовал за подход от шага 1-4 я должен связать клиентскую сущность из таблица клиента в случае создания нового счет, но в случае обновление / печать счета, который я имею связать клиентскую сущность из таблица счетов в противном случае данные не будет последовательным или целым числом ... Так как я могу сохранить целостность данных без создания спагетти-кода в DAL для обработки этого обычая требования к привязке данных ??]
2. Я прошел через систему, которая была сохранение всех предыдущих версий данные объекта до обновления «ведение истории всех версий». Если я хочу использовать тот же метод для избежать пользовательского связывания, как я могу сделать это с точки зрения дизайна базы данных "Использование MYSQL"? [Объяснение: некоторые счета, созданные с помощью версии 1.0 клиент, то информация о клиенте обновился и его версия стала 1.1 и новые счета, созданные с последними версия ... Так хорошо ли следовать эта методология? и как я должен спроектировать мои объекты / таблицы, чтобы выполнить требования объекта управление версиями и связывание?
3. Пожалуйста, предоставьте любую книгу или ссылку это может ударить меня в праве направление

Спасибо

Answer 1

Что вам нужно сделать, это оставить стол таким, какой он есть. Вы правы, вы должны хранить информацию о клиенте в счете для истории, куда были отправлены товары. Когда она изменяется, вы НЕ должны обновлять эту информацию, за исключением любых счетов, которые еще не были отправлены. Для поддержки этого типа информации вам необходим триггер в таблице клиентов, который ищет счета-фактуры, которые не были отправлены, и автоматически обновляет эти адреса.

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

Целостность данных в этом случае просто через внешний ключ к идентификатору клиента. Сам идентификатор никогда не должен изменяться или быть разрешенным для изменения пользователем и должен быть суррогатным числом, таким как целое число. Так как вы не должны изменять адресную информацию в фактическом счете-фактуре (если только он не был отправлен, в этом случае вам лучше его изменить или товар будет отправлен не в то место), этого достаточно для сохранения целостности данных. Это также позволяет вам увидеть, куда на самом деле был отправлен товар, но все же посмотреть текущую информацию о клиенте с помощью внешнего ключа.

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

Answer 2

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

Извините, что добавил это как новый ответ, но кнопка "Добавить комментарий" по-прежнему не отображается.

«Его замысел» действительно не неправильный ... потому что он нормализован !!!

Нормализовано, потому что не всегда верно, что адрес, соответствующий счету, функционально зависит исключительно от идентификатора клиента.

Итак: нормализация, да, я так думаю. Не то, чтобы нормализация была единственной проблемой, связанной с этим.

Answer 3

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