на который не получается нормально ответить гуглением.
Допустим, я думаю о SaaS для корпоративных клиентов. База на postgres, в качестве бэкенда - supabase.
В рамках одной организации могут быть разные участники. Также организации могут захотеть хранение персданных, выгрузку всей инфы по компании и т.д.
с такими требованиями, как я понимаю, сделать просто базу и накрыть её RLS-политикой не выйдет, т.к. в таблицах одной базы будут жить данные по разным компаниям.
При этом под каждого заказчика разворачивать свою копию базы может быть несколько проблематично.
Одно из возможных решений: сделать структуру базы в какой-нибудь схеме (public schema, например), и затем при добавлении нового клиента (компании) создавать под неё нового юзера в базе, копировать пустую public схему в новую, назначать этого юзера владельцем схемы.
Правильно ли я понимаю, что при копировании схемы также можно скопировать все RLS-политики, триггеры, функции и т.д.? Если направление в принципе верное, то насколько это поддерживает supabase? Вопрос для тех, кто с этим сервисом знаком.
Это бредовое замечание. Допустим вы разделите их по схемам, нафига наши данные лежать в одной базе(одной куче), разделим по базам, почему наши данные лежать в одном кластере/одной куче. Сделаем два кластера, нафига наши данные лежать на одном сервере, все яйца в одной корзине, будет скомпрометирован сервер данные всех пользователей окажутся под угрозой, опять куча. На сегодняшний день ИБ это неконтролируемое грибоедово, единственный способ пресечения потребления грибов это их недостаток, с учетом того что компетентных специалистов мало, зато каждый фантазёр рецепт один меньше пищи меньше вопросов. А если серьезно нужна открытая площадка для дискуссии пока ее нет это безобразие не кончится...
Полегче, а. ХБ-шка зимой от морозов не защищает. Чё теперь, трусы не надевать?
Как скажете но сути это не меняет
Обсуждают сегодня