Несколько баз данных в EF6

Question

Мы участвуем в совершенно новой разработке, в которой мы перерабатываем нашу текущую платформу веб-магазина. В текущей платформе мы не используем EF6 ни другие ORM, а храним процедуры доступа к db, но в новом здании мы работаем.

У нас есть сомнения относительно дизайна базы данных новой платформы. В текущей платформе мы используем несколько разных баз данных в зависимости от их содержимого. Например, у нас есть выделенные базы данных для хранения информации для каталогов продуктов других выделенных db для обработки заказов. В настоящее время весь доступ к данным осуществляется через хранимые процедуры, поэтому у нас нет проблем с связями между различными базами данных. Проблема возникает у нас, когда мы начали использовать EF6. В этом случае каждая БД связана с контекстом, и невозможно узнать данные из одного контекста другому , если мы не реализуем непосредственно в исходном коде эти отношения, используя различные контексты. Похоже, это означает, что мы потеряем силу EF6.

Вопросы, которые у нас есть: Плохо ли дизайн, поддерживающий разные базы данных для одного и того же приложения с использованием EF6? В случае, если это плохой дизайн и выбор для одной базы данных, производительность будет оптимальной даже для сотен таблиц (почти 1000) с несколькими TBytes информации? , с другой стороны, в случае выбора дизайна, в котором появляется несколько bbdd (в нашем случае это было бы намного лучше), каков наилучший способ обработки EF6?

Большое вам спасибо за помощь!

Answer 1

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

Вы можете использовать хранимые процедуры в EF, но, насколько я понимаю, вы думаете прекратить их использовать.

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

Итак, на мой взгляд, вы можете изменить подход.
Если у вас есть проблемы с резервными копиями, вы можете оштрафовать огромные таблицы (я думаю, таблицы фактов и таблицы с картинками) и создавать кросс-базы данных. Кстати, также, ссылка на ссылочную целостность базы данных не поддерживается в SQL Server, поэтому вам нужно написать триггеры, чтобы проверить ее.
Если вам нужно разделить различные функции приложения (т. Е. WMS, CRM и т. Д.), Вы можете использовать пространства имен, не беспокоясь о том, как таблицы хранятся в БД.