Эта схема по сути является ручным разделением таблицы CustomerCredit. Лучшим решением было бы то, которое делает разделение прозрачным для всех пользователей. Код не должен знать, как данные разделены.
Решения для баз данных
Преимущество решений для баз данных состоит в том, что они прозрачны или почти прозрачны для пользователей и требуют минимального обслуживание
Разделение таблицы
Чистым решением было бы использование разбиение таблицы , делая различные разделы прозрачными для всех пользователи. Раньше разделение таблиц использовалось только для Enterprise, но оно стало доступно во всех выпусках, начиная с SQL Server 2016 SP1, даже Express. Это означает, что это бесплатно во всех версиях, которые все еще поддерживаются.
Таблица разделена на основе функции (например, функции на основе даты) и хранится в разных файлах. Когда это возможно, оптимизатор запросов может проверять границы раздела и условия запроса и использовать только файл, содержащий соответствующие данные. Например, в таблице с разделением по дате запросы, содержащие фильтр даты, могут выполнять поиск только по соответствующим разделам.
Секционированные представления
Другой вариант: по крайней мере, начиная с 2000 года, это использование представлений секционирования , по сути, представления UNION ALL, объединяющего все разделы таблицы, например:
SELECT <select_list1>
FROM [202001].[CustomerCredit]
UNION ALL
SELECT <select_list2>
FROM [202002].[CustomerCredit]
UNION ALL
...
SELECT <select_listn>
FROM Tn;
EF может отображать сущности в представления вместо таблиц , Если критерии для обновляемых представлений соблюдены, само разделенное представление будет обновляемым и любые изменения будут внесены в правильную таблицу.
Оптимизатор запросов может использовать ограничения CHECK для таблиц для поиска только в одной таблице. в то же время, как работает секционированные таблицы.
Решения для кода
Для этого требуются необработанные SQL запросы и способ определения правильной таблицы / схемы при каждом изменении. Это требует изменений в приложении каждый раз, когда изменяется разбиение таблицы, будь то модификации кода или изменения в файле конфигурации.
Во всех случаях один запрос может считывать только одну таблицу за раз
Сохранить ADO. NET
Одна из возможностей - продолжать использовать ADO. NET, заменяя имя таблицы / схемы в шаблоне запроса. При необходимости код должен отображаться на объекты, так же, как он это уже делал.
EF Raw SQL
Другой вариант: использовать функции SQL EF, например EF Core FromSqlRaw , для запроса из определенной таблицы c, аналогично ADO. NET. Преимущество заключается в том, что EF отобразит результаты запроса на объекты. В EF Core необработанный запрос можно комбинировать с операторами LINQ:
var query=$"select * from [DatabaseName].[{schemaName}].[CustomerCredit]"
var credits = context.CustomerCredits
.FromSqlRaw(query)
.Where(...)
.ToList();
Dapper
Другой вариант - использовать Dapper или другой micro-ORM с запросом ad-ho c, аналогичным ADO. NET, и сопоставляет результаты с объектами:
var query=$"select * from [DatabaseName].[{schemaName}].[CustomerCredit] where customerID=@ID";
var credits=connection.Query<CustomerCredit>(query,new {ID=someID});