Существуют таблицы базы данных, в которых хранятся копии данных, и, к сожалению, автор этих таблиц, к сожалению, не спроектировал использование отношений (FK, Guid и т. Д.) При обращении к данным при необходимости, но фактически скопировал сами данные вдругие таблицы ... может быть, это было для сокращения накладных расходов и облегчения извлечения всей необходимой информации в одном запросе.
И теперь возникают проблемы, очевидно, потому что другой человек написал такой код, скажем, «данные 1» в таблице. Пользователь может изменить A, когда эти «данные 1» также находятся в «таблице B» и «таблице C». По крайней мере, это не совсем безнадежно, потому что есть еще один столбец в «таблице A», скажем, «ключ 1», который можно использовать в паре с «данными 1» при копировании в «таблицу B» и «таблицу C», поэтому, по крайней мере,отношение не теряется при изменении пользователем.
В настоящее время код использует шаблон MVC asp.net, и я понимаю, что исправление, вероятно, зависит от того, как написан код и все это, однако кто-нибудь знает хорошо известное исправлениедля вопроса, как это? Шаблон проектирования, архитектура и т. Д. В настоящее время реорганизация схемы базы данных не является вариантом и должна быть обратно совместимой, то есть должна быть способна обрабатывать старые форматы без ключей, но план обновляет уже сохраненные данные, чтобы в конечном итоге иметь ключи.