arkhimedPetro123skyANA,
я думаю, ему нужно как можно проще.
Из-за этого он шифрует в логин имя поддомена. Что я не очень приветствую.
ТЗ (которое он не колется):
- каждой организации свой экземпляр 1С.
- авторизация самой 1С должна дружить с авторизацией и билингом надсистемы Облако.
- смена версий ПО в облаке решается желанием заказчика (может заморозить).

Уважаемый Petro123,

еще раз повторю:
нет никакого 1С, разработка полностью своя с нуля.
думаем использовать подход хранения в разных схемах по нескольким причинам:
1. упрощенная разработка схем таблиц и процедур (нет необходимости везде вводить поле AccountId).
2. для некоторых крупных клиентов можно предоставить прямой доступ к их схеме.
3. всегда можно достаточно легко вынести данные клиента в отдельную бд и отдать ему.
4. у каждого клиента будет достаточно много данных, несколько миллионов строк. таких клиентов будет, например, около 100.
намного проще разнести их данные на несколько бд и серверов, причем в зависимости от требований клиентов можно будет предоставлять разный регламент бекапирования и т.п.

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

при этом буду рад любым замечаниям и идеям. сейчас проект в стадии осмысления и всё еще можно поменять.100-200 миллионов строк - это не много.

Понимаете, пока не понятно на чём основывается Ваш выбор.

arkhimedskyANA,

по поводу зачем несколько серверов.

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

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

если не сложно, расскажите как у вас? всё находится в одном дц?Да, на данный момент всё в одном ДЦ. Клиенты разбросаны от Калифорнии до Австралии.

arkhimedPetro123пропущено...

разумеется вам как то надо разделять БД между заказчиками.
Как вы "приложениеА" для разных заказчиков в одной БД будете держать. Это и не обсуждается.
OFF


Вы не совсем меня поняли.
Мы не собираемся готовое приложение переносить "в облако" как есть.
Схема данных проектируется с нуля.
Поэтому в принципе мы можем в каждой табличке предусмотреть ссылку на клиента.
Но на данный момент мне не кажется, что по трудозатратам это будет оптимальным вариантом.Самописный шардинг всегда трудозатратней того, когда всё в одной БД.

arkhimedОлег2015arkhimed,

Отправной точкой подсистемы аутентификации должны быть готовые промышленные решения одинаково хорошо работающие с протоколами любимыми Microsoft (WS-Federation, WS-Trust), так и другими, более распространенными, например SAML2p, ведь, Вы не предполагаете ограничить доступ к API для java-клиентов. На стороне приложения уже стало классикой аутентификация и авторизация на WIF.

спасибо!
для меня главное определиться с технологией microsoft, которая сейчас актуальна, и ее копать.
в последнее время у них такой зоопарк технологий вырос, что сложно понять какую выбрать.А у организации есть сотрудники? Им будет даваться доступ? Кем, какой?

Какой-нибудь OAuth прикрутить не проблема, но нужен-ли он на первом этапе...

arkhimed, как организации будут регистрироваться в вашей системе? Какие credentials при этом указывать?