Как правильно отделить автоматически заполненные таблицы от заполненных вручную таблиц в SQL Server?

Question

Допустим, у меня есть две таблицы в базе данных:

[Movies] (Scheme: Automatic)
----------------------------
MovieID
Name

[Comments] (Scheme: Manual)
----------------------------
CommentID
MovieID
Text

Таблица «Фильмы» обновляется службой каждые 10 минут, а таблица «Комментарии» обновляется вручную пользователями базы данных.

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

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

Редактировать / Уточнить:

Просто чтобы уточнить. Таблицы примеров полностью составлены. В действительности БД будет содержать такие объекты, как серверы, приложения, заметки о приложениях, номера версий и т. Д. Информация, относящаяся к серверу, будет заполняться автоматически, но некоторые детали приложения будут заполняться вручную. Это может быть информация, такая как специальные конфигурации и тому подобное. Даже если запись с сервера будет удалена, заметки приложения на этом сервере по-прежнему ценны и не должны быть удалены.

Answer 1

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

Answer 2

"Я планировал добавить внешний ключ это не поддерживает референс целостность и только каскадные обновления, не удаления. "

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

Answer 3

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

Answer 4

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