Базы данных и Deep Copy

Question

Если я захочу сделать глубокую копию объекта, хранящегося в моей реляционной базе данных, обязательно ли я сделал что-то принципиально неправильное архитектурно? Это другой подход к другому (гораздо более подробному) вопросу, который я задал, но не получил большого ответа на вопрос Копирование данных реляционной таблицы .

Answer 1

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

Answer 2

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

Answer 3

Не обязательно.Я сделал это сам с большим успехом, чтобы реализовать схему управления версиями.По существу, все графики могут быть версионными (с использованием составного ключа, где одна часть ключа является идентификатором вещи, а другая - номером версии), и мы легко получим доступ ко всем предыдущим версиям графика или подграфов.*

Для ясности, БД Архитектор рекомендовал эту схему;его мнение имело большое значение, и решение не было моим первым выбором.Но в итоге все получилось очень хорошо.

Answer 4

Это зависит от того, что представляют ваши реляционные таблицы, и какие из ваших сущностей сгруппированы для создания «бизнес-объекта». Например, если у вас есть реляционная модель системы управления контентом с таблицей «Postings» и таблицей «Text_lines», где каждая публикация состоит из списка текстовых строк, вероятнее всего будет действительная копия вашего бизнес-объекта «Posting». быть глубокой копией сущности Postings вместе с принадлежащими сущностями Text_lines.

С другой стороны, имея две таблицы «Отдел» и «Сотрудники», правильная копия отдела, скорее всего, не является полной копией (по крайней мере, если каждый сотрудник связан ровно с одним отделом в одной точке время). В схеме реляционной базы данных такого рода различия часто идут рука об руку с проверкой ссылочной целостности, назначенной отношениям. Отношение «Postings» -> «Text_lines» можно смоделировать, используя ограничение внешнего ключа с целостностью «ON DELETE CASCADE» (конечно, если ваша база данных поддерживает это). Однако в "Department" -> "Employees" не должно быть такой проверки "ON DELETE CASCADE".