David_Wimbley
То, о чем вы просите, - это довольно большая задача, которую кто-то без опыта не может начать строить. Я понимаю, что вы больше хотите понять, как он построен, но если у вас есть команда, чтобы справиться с этим, как вы говорите, Я бы сказал, что вам лучше всего задавать свои вопросы/работать со своей командой, чтобы понять проект, который вы пытаетесь построить. В конце концов, именно они должны понимать требования и являются единственными, кто сможет сказать вам, могут ли они построить то, что вы хотите.
Но чтобы ответить на ваши основные вопросы здесь. Вы спрашиваете, следует ли создавать одностенантное или Мультитенантное приложение.
Один арендатор означает 1 клиента на экземпляр вашего приложения.
Мульти-арендатора, то есть более, чем 1 клиента для каждого экземпляра приложения.
Существует много различных способов создания приложения такого масштаба, но, основываясь на ваших дополнительных вопросах, давайте просто предположим, что вы идете по мультитенантному маршруту.
Цитата:
Но я просто хочу знать, как обращаться с разными школами на одном сайте.
Я имею в виду, что у меня есть "School_A" или "School_b". Эти данные не должны показываться друг другу пользователями.
При настройке новых "клиентов" на этой платформе у вас будет какой-то способ привязать пользователей к ее данным, чтобы пользователи School_A были назначены/привязаны к данным School_A, но не к каким-либо другим данным клиентов. Или вы могли бы привязать пользователей к "компании" или некоторому уровню записи, который может сгруппировать много пользователей по одному идентификатору. Тогда на вашем столе "клиенты" у вас может быть CompanyId, который связывает клиентов с компанией. Таким образом, все пользователи, привязанные к компании, могут видеть только данные клиентов этой компании. (Пример: пользователь A, привязаны к компании Б. Компания Б привязана к School_A поэтому любой пользователь привязан к компании B может видеть только данные по School_A).
Цитата:
Я наблюдал многие веб-приложения, такие как jira и некоторые сборы за управление проектами, когда пользователь регистрируется на веб-сайте, он создает свой поддомен.
Например www.abc.com\schoolA и еще www.abc.com\schoolb
Существует целый ряд способов добиться этого. Лучше всего поговорить с вашей командой, чтобы понять, каковы их возможности. Вы могли бы раскрутить 1 сервер на одного клиента, но хотели бы автоматизировать это или просто иметь его, как ваш пример.
Цитата:
Более того, когда я входю в систему с моими учетными данными, система знает, на какую сущность (School_A или School_B) нужно перенаправить.
Смотрите мои комментарии выше о связывании пользователей с компанией. Компания может быть неправильным термином здесь, но если вы собираетесь иметь много пользователей в школе. Возможно, вы захотите сгруппировать этих пользователей в компании, чтобы упростить задачу. Таким образом, "администратор" "компании" может зарегистрировать больше пользователей и связать их соответствующим образом.
Это или вам просто нужно будет создать таблицу сопоставления школ с пользователями, которая сопоставляет идентификаторы пользователей со школами. Это может плохо масштабироваться в зависимости от того, в каком направлении вы идете с вашим приложением.
Цитата:
Во-вторых, в каждом новом реестре организаций. создает ли система другую базу данных и получает ли результат форму, что база данных или база данных остаются одинаковыми для всего веб-приложения и дифференцируются с помощью уникального идентификатора школы.
Я предлагаю вам взглянуть еще на одного клиента АРС мультитенантных приложений. Если вы не понимаете эту концепцию, то, если вы просто не задаете эти вопросы для своей собственной выгоды, ваша команда разработчиков должна понять.
Короче говоря, запуск 1 дБ на одного клиента может быть экономически неэффективным, если это запуск, но если данные сверхчувствительны (например, номера социального страхования), вам может потребоваться одно приложение-арендатор. Я не знаю ваших надежд, мечтаний и желаний на долгосрочное будущее вашего приложения, поэтому из того, что я знаю, я бы пошел мультитенантным.
Цитата:
я думаю, что эта одна база данных может убить постоянство, когда данные увеличатся для всей организации.
Если вы не используете какую-то базу данных без имени, то 1 единственный сервер DB/DB, скорее всего, будет в порядке. Опять же, я недостаточно знаю о вашем приложении, но очень сомневаюсь, что вы будете прокачивать достаточно транзакций через эту единственную базу данных, чтобы это было проблемой. Но опять же, это зависит от потребностей вашего приложения.
Даже если это так, есть варианты зеркального отображения или размещенные опции, такие как RDS, которые снимают с вас ответственность за системного администратора вашей БД.
Короче говоря, это довольно амбициозный проект, за который можно взяться без особого опыта. С широким охватом многих из этих архитектурных концепций, вы должны сделать много исследований.