Доступ к данным из других баз данных - архитектура системы

Question

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

У нас есть еще одно приложение, которое работает по аналогичной схеме, главное отличие в том, что у него много разных «установок», каждый из которых обращается к своим отдельным базам данных.

Все эти веб-сайты работают на одном сервере, а все базы данных находятся в одном экземпляре SQL-сервера.

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

Теперь у нас есть новое изменение, которое потребует от меня вернуть список данных из мультитенантной системы, но отфильтровать его на основе критериев, хранящихся в базах данных другой системы. Я вижу несколько способов сделать это, но мне было интересно, есть ли у кого-нибудь яркие идеи:

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

2. Написание динамического SQL на уровне базы данных для объединения на .dbo.table, что также немного уродливо и может быть сложно поддерживать.

3. Копировать данные из одной базы данных в другую. Это то место, к которому я стремлюсь, однако тогда возникает риск несогласованности данных.

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

Answer 1

В зависимости от размера бизнеса я иду с #1 или #2.

#1 более масштабируем и хорош для гетерогенных клиентов, но сложнее в реализации и обслуживании. Поскольку у вас нет общедоступных API, вы можете перейти на #2.

#2 нужен опытный администратор базы данных и очень подвержен ошибкам

#3 - худшее решение для ИМО, поскольку избыточность может возникнуть, и позже ее трудно будет решить.

То, что я предлагаю, - это краткосрочный план и долгосрочный план. В краткосрочной перспективе используйте #1 или #2 и одновременно перепроектируйте вашу базу данных. Затем вы можете добавить новую модель данных в систему, и она может сосуществовать с устаревшей базой данных. Когда вы будете уверены в его функциональности, переключитесь на новую базу данных, но все равно останетесь lgacy системой. И, наконец, когда новый БД не имеет проблем через некоторое время, выйдите из старого БД из схемы.

Answer 2

Не меняйте модель данных.Это рискованно.Просто создайте поверх него еще одну абстрактную оболочку.

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