Итак, мы создаем мультитенантную систему для работы в качестве службы. Мы начинаем с нуля. Мы следуем за DDD; домен имеет (на данный момент) ~ 20 сущностей в нем, а позже будет больше. Он должен быть размещен нами, географически избыточным (n + 1 из всего, кроме запросов SQL ;-)), и гибким дизайном (ну, это последнее - наше собственное требование, а не бизнес), хотя они хотят, чтобы мы могли поменять его легко по требованию конечно). Мы основаны на .NET и будем использовать реляционную базу данных для нашего резервного хранилища. Мы не против использования инструментов и библиотек с открытым исходным кодом (вообще).
Одной из обязательных особенностей бизнеса является то, что некоторые сущности могут быть расширены арендаторами системы. Например, клиент A может захотеть, чтобы сущность Foo имела свойства Title и Abstract, тогда как клиент B может пожелать, чтобы сущность Foo имела свойства Date Publish и Directed-By, а не Title Title.
Может также случиться так, что он должен поддерживать данные на нескольких языках для арендаторов, которые хотят этого - например, один арендатор может быть заинтересован в переводе всей своей учетной записи на два (или более) языка; и «статические» строки, и строки, присоединенные к объектам в виде данных.
Так. Произвольное количество полей (помимо некоторой общей базовой линии; в этих объектах есть определенные вещи, которые получат все арендаторы), определяемое клиентом (где они также могут определять тип данных). Возможность перевода данных (без дублирования сущностей - как в, без настройки одного набора на английском языке, а затем настройки того же набора на французском языке). Кроме того, строго типизированное, доступное для поиска, запрашиваемое хранилище резервных копий (так что нет никакого лишнего материала, попадающего в XML-поле, если только у него нет способа получить строго типизированный и доступный для поиска). Performant (но это вторичное требование; эта функция достаточно важна, чтобы при необходимости купить оборудование).
Объемы данных? В нашей нынешней системе «средний» клиент имеет сотни объектов, а «большой» - тысячи объектов. Запросы обычно фильтруют эти списки для отображения в промежутке между 10-200, и наиболее распространенная вещь, которую нужно сделать, будет включать, возможно, полдюжины объектов (которые в новой системе должны быть расширяемыми).
Другие моменты? У каждой организации есть прямая ссылка на владельца, которому она принадлежит.
Как это происходит в .NET-стране? Предполагается, что мы помещаем наши объекты в контейнер IoC и собираем их вместе на лету во время выполнения - но как можно сопоставить это с реляционной базой данных?
Я также помню, как читал пост Айенде об этом с Lucene.NET из какого-то значительного времени назад, что звучит неплохо, но в настоящее время у нас нет опыта работы с Lucene.NET или nHibernate. (В настоящее время мы собираемся использовать Linq2Sql для нашего ORM, но если нам нужно изменить это, чтобы поддержать это, я лично буду счастлив, если честно).
Я прочитал этот поток списка разработчиков Dev * , который связан с Ayende, и кажется, что в nHibernate есть нечто, называемое IUserType, которое может помочь - интересно, можем ли мы применить это, потянув соответствующий наш IoC для каждого арендатора? Таким образом, по одному IUserType на каждого клиента для каждого расширяемого объекта и сохраняйте сами данные в столбце XML внутри SQL Server (наша наиболее вероятная СУБД).
Наконец, я только что прочитал одно предложение о динамическом изменении таблицы DB для каждой сущности на каждого арендатора - но это звучит довольно ... Честно, честно! Я имею в виду, что может работать, но звучит не очень хорошая идея, чтобы дать возможность сделать это арендаторам (которые могут быть менее технически подкованы). Я полагаю, что это может быть доступно только для администраторов ...