#sql #sql-server
#sql #sql-сервер
Вопрос:
Я большой поклонник целостности данных, когда дело доходит до базы данных. Мой образ мышления :
- Лучше применять ограничение непосредственно в базе данных (пример: внешний ключ), чем либо ждать сбоя приложения из-за отсутствия строки в таблице, либо вручную добавлять это ограничение повсюду в коде приложения.
Проблема
У нас есть несколько таблиц, которые дублируются в нескольких базах данных и используются несколькими приложениями. Одним из примеров является User таблица.
У нас есть пользователи почти во всех приложениях. Проблема в том, что в данный момент эти пользователи обрабатываются отдельно, в то время как они должны, по крайней мере, я думаю, быть объединены вместе. В настоящее время повсюду много дубликатов и устаревшая информация о пользователе повсюду. Когда пользователь обновляется в одной базе данных / приложении, он не обновляется в другой, но это один и тот же пользователь, поэтому его информация должна обновляться везде.
Что мы планируем сделать
Мы думали о создании справочной базы данных для перегруппировки всей этой информации. Например, вся информация о пользователях будет храниться в одной базе данных, и каждое приложение может использовать эту базу данных для доступа к необходимой им информации о своем пользователе.
Вопрос 1: Это хорошая идея? Есть ли другая альтернатива, чтобы избежать дублирования / устаревших данных повсюду?
Новая проблема
Хотя группировка всей пользовательской информации в единую базу данных может решить проблему дублирования / устаревшей пользовательской информации, это создает новую проблему целостности данных :
- Мы больше не можем создавать ограничение внешнего ключа для
Userтаблицы, поскольку она находится в другой базе данных.
Конечно, к пользовательским таблицам легко получить доступ с помощью представлений, но вы также не можете применить ограничение внешнего ключа к представлению…
Вопрос 2: Итак, каковы мои варианты, если я хотел бы сохранить ограничения целостности данных непосредственно в базе данных?
Комментарии:
1. Ваш вопрос слишком широкий. Это действительно зависит от того, что вы цените больше, целостность данных или централизацию данных. Мы ничего не знаем о вашем бизнесе. Вы серьезно относитесь к аудиту или вас не волнуют изменения в вашей БД… Если важна целостность данных, сохраняйте отдельных пользователей и создавайте задания синхронизации, чтобы они были свежими в каждой базе данных.
2. Вопрос выходит за рамки вопроса, но это больше похоже на то, что у вас действительно должна быть одна база данных, где разные приложения в некоторых случаях имеют свою собственную схему (например, dbo) и делают больше для координации усилий по разработке среди ваших групп приложений.
3. @T.S. Я знаю, что вопрос широкий, но я не хочу задавать слишком конкретный вопрос и упускать из виду гораздо лучшее решение реальной проблемы, которая заключается в целостности и централизации данных. Наиболее важным моментом является централизация данных.
4. У вас может быть центральная база данных для пользователя и скалярных свойств. CentralDB.dbo.CentralUser. CentralUserSurrogateKey. Вы можете добавить сюда скалярные данные, такие как LastName, FirstName. Затем в каждой БД у вас есть MyApplicationDB.dbo.User.UserSurrogateKey (PK) и MyApplicationDB.dbo.User . CentralUserSurrogateKey («свободный» внешний ключ). Эти 2 столбца — единственное, что есть в этой таблице. Вы используете свой MyApplicationDB с помощью этого UserSurrogateKey. Вы можете написать триггер для каждой таблицы, чтобы убедиться, что «Пользователь. CentralUserSurrogateKey» существует в CentralUser. CentralUserSurrogateKey. Не очень хорошо, я знаю.
5. Я действительно сделал это один раз с Asp.Net Поставщик членства (таблица aspnet_Users). Мы сохранили «Пользователей» в этой таблице и использовали Asp.Net поставщик членства для создания / обновления и взаимодействия с пользователями. Затем мы написали плагин «aspnet_Users для моего приложения», который будет делать то, о чем я описал. Поместите это aspnet_Users. Идентификатор пользователя (копия) в «MyAppDB». Все работало нормально. Но с «FK не может пересекать границы одной базы данных» вы ограничены в том, что вы можете сделать.
Ответ №1:
Вопрос 1: Это хорошая идея? Есть ли другая альтернатива, чтобы избежать дублирования / устаревших данных повсюду?
Проблема, с которой вы столкнулись, не уникальна. приложения разрабатывались целую вечность, чтобы работать в пределах собственной области, владеть собственными данными и быть «автономными». Поскольку промышленность осознала стоимость обслуживания отдельных систем и ценность качества данных, они стремились улучшить качество и сократить накладные расходы. То, во что вы ввязываетесь, является причиной N-уровневой разработки и общего специфичного для компании кода. Например, служба или «DLL», которая запутывает уровень данных, позволяя разработчику не знать о базе данных, в то время как gaing контролирует общую информацию. Это хорошая идея; если ваша компания растет, вы действительно не можете позволить себе этого не делать.
Альтернативой является идентификация одного авторитетного источника и репликация информации из него во все другие источники; или требовать, чтобы подсистемы сообщали авторитетному при изменении информации, управляя конфликтами, если данные изменены в обоих местах.
Вопрос 2: Итак, каковы мои варианты, если я хотел бы сохранить ограничения целостности данных непосредственно в базе данных?Идентификация авторитетного источника и репликация между приложениями. Убедитесь, что обновления, сделанные в подсистемах, распространяются на master, а master распространяется на дочерние элементы
По-прежнему требуется, чтобы уникальный идентификатор существовал в различных системах, позволяющих управлять целостностью; но имейте все «связанные значения», которые дорого поддерживать в авторитетном источнике. Рассмотрите возможность установления связи между пользователем и приложением в пользовательской базе данных, что добавило бы уровень безопасности к системам. и обратите внимание, когда пользователи находятся в системе или больше не находятся в ней (не только наличие записи, но и даты начала и окончания. пользователь с конечной датой по-прежнему не имеет доступа к приложению.
Ответ №2:
Я бы изучил функцию репликации транзакций, если вы используете sql-server.
Он может быть настроен как двунаправленный, так и односторонний.
Односторонние изменения в вашем главном пользовательском репозитории будут внесены в транзакционные изменения для подписчиков, однако подписчик также может опрашивать и извлекать данные из издателя. Важно отметить, что при этой настройке ваша локальная копия пользовательской таблицы не может быть записана, иначе это приведет к сбою репликации, что потребует повторной инициализации подписки.
Двунаправленный — это по своей природе более разговорчивый, однако, как издатель, так и подписчик могут быть обновлены.
Весь процесс имеет дополнительный более высокий уровень оркестровки с использованием выделенного экземпляра sql, используемого в качестве установленного распространителя для мониторинга нескольких публикаций и подписок.
Зачем изобретать велосипед. Если вы используете mssql enterprise, то это стандартная практика.
Комментарии:
1. Вы бы сказали: «Поместите как можно больше данных в глобальную базу данных» или «Поместите как можно меньше данных в глобальную базу данных»? Например, если я создам минималистичную таблицу пользователей в глобальной базе данных с электронной почтой, именем и фамилией, этого должно быть достаточно, чтобы однозначно идентифицировать конкретного пользователя. Тогда я мог бы сохранить данные, относящиеся к конкретному приложению, в базе данных приложения. Но у меня все еще есть некоторый риск дублирования данных: S
2. Да, я уверен, что все ваши приложения используют одно и то же подмножество данных, например, те, которые вы перечислили. Выделение такого количества данных вместе с первичным ключом пользователя в общую «пользовательскую» таблицу удовлетворит вашим ограничениям внешнего ключа и даст вам близкие (в режиме реального времени) обновления имен пользователей, паролей, электронной почты и т. Д. И т. Д. На мой взгляд, любые данные, относящиеся к конкретному приложению, должны быть привязаны к пользователю, но сохранены в другой таблице. Это из чистого представления базы данных. В ваших приложениях могут быть другие ограничения, которые делают это недействительным.