Linq 2 Sql и схемы динамических таблиц

Question

Первый фон. Наше приложение построено на ASP.NET MVC3, .NET 4.0 и использует Linq-to-Sql (PLINQO) в качестве основного средства доступа к данным. Наше веб-приложение представляет собой мультитенантную / мультиклиентскую систему, где каждый клиент получает свою собственную базу данных Sql Server. До сих пор каждая база данных Sql Server имела одинаковую схему.

Часто клиенты просят нас отследить настраиваемые поля в своей базе данных, которые другие клиенты не отслеживают. Мы справились с этим, зарезервировав несколько пользовательских полей в БД в наших основных таблицах. Например, наша таблица виджетов может иметь поля CustomText1, CustomText2 .. CustomText10 и поля CustomDate1, CustomDate2..CustomDate10. Опять же, все наши схемы для клиентов одинаковы, поэтому Linq-to-Sql обрабатывает эти поля так же легко, как и любое другое поле.

Теперь мы столкнулись с проблемой, когда клиент хочет несколько сотен полей CustomBool, но другие не нужны. Итак, в основном, мы ищем способы по-прежнему использовать Linq-to-Sql, но работаем ли он против потенциально разных схем в зависимости от базы данных, к которой он подключен (хотя они отличаются весьма специфическим образом).

Слишком много кода уже построено на Linq-to-Sql и доступе к генерируемым им классам Widget, и я бы не хотел просто возвращаться к прямому SQL.

Я видел ответы здесь и в Интернете о способах доступа Linq к Sql к разным таблицам с одинаковой схемой, но я не нашел хорошего ответа на одно и то же имя таблицы в разных БД с разными столбцами.

Возможно ли это?

Answer 1

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

Мы делаем это часто и обычно у нас есть помощники для правильного приведения свойств, например

Service.GetProperty<bool>("SomeCustomProperty")

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

Чтобы достичь этого, вам действительно необходимо создать базу данных на основе вашего кода (проектирование на основе домена), что даст вам гораздо большую гибкость, т.е. вы можете загрузить специфическую для арендатора конфигурацию (набор классов, бизнес-правила и т. Д.)) во время выполнения и используйте это для генерации / проверки вашей схемы.

Обновление

Было бы хорошо, если бы вы могли точно определить, какой подход к проектированию вы выбрали, т.е. используете ли вы дизайнер Linq исоздание вашей модели из базы данных?

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

Трудно найти решение, не предлагая другую технологию.Реляционные базы данных SQL на самом деле не подходят для моделей динамических доменов.Возможно, вам лучше использовать базу данных документов, такую ​​как MongoDb или RavenDb , где вы не привязаны к определенной схеме.Вы могли бы даже использовать эти только для ваших пользовательских свойств.

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

Айенде опубликовал целый ряд публикаций по вопросам Multitenancy и охватывает модели доменов, специфичные для арендаторов.Она начинается здесь и может быть вам полезна.