Гибкость и конфиденциальность базы данных, скрытая структура, совместимость программного обеспечения и «публичные» разрешения

Question

Я один из тех, кто недавно решил перейти с MySQL на PostgreSQL, и вместе с этим многие старые привычки разрушаются.Однако в MySQL есть функции, которые я хотел бы сохранить в PostgreSQL.

Итак ... themes :

1. Пользователь должен иметь возможность создавать таблицы подограниченное пространство имен.
2. Таблицы одного пользователя не должны быть видны другим пользователям по умолчанию (как данные, структура, хранимые процедуры и так далее).
3. При желании пользователю должно быть предоставлено право на GRANT.разрешения другим пользователям.
4. Разрешение по умолчанию для новых пользователей - не иметь разрешения (ничего не читать, писать даже меньше)
5. Поддерживать совместимость с приложениями, не поддерживающими схему.

Точка 1:

В MySQL решение состояло в том, чтобы позволить пользователю создавать базы данных по критериям «username_%».В PostgreSQL я думал о наличии одной базы данных на пользователя, чтобы они могли создавать столько схем, сколько они хотят.Однако существует ограничение на невозможность выполнения объединений между базами данных, только между схемами в одной базе данных.

Возможность иметь все схемы PostgreSQL в одной базе данных не полностью отбрасывается.Но тогда он страдает от следующего пункта ...

Пункт 2:

Прочитав этот вопрос Я был склонен думать, что единственныйспособ сделать данные полностью конфиденциальными было использовать разные базы данных.Тем не менее, я не могу понять, как это сделать, и, с другой стороны, это вступает в конфликт со способностью выполнять объединения, упомянутые в предыдущем пункте.

Точка 3:

Возможно ли это, или вам нужна привилегия «Создание ролей» и создание новой роли для данной таблицы / схемы.

Точка 4:

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

Пункт 5:

Некоторые из программ, которые я использую с MySQL, над которыми у меня нет прямого контроля над действиями, которые они выполняют над базой данных, не поддерживают схемы.Это означает, что они просто игнорируют слой схемы.Для этого PostgreSQL по умолчанию предоставляет «публичную» схему.Однако в некоторых случаях это все еще немного неудобно.

Это также означает, что по умолчанию мне нужна одна независимая база данных для каждого программного обеспечения / инструмента, иначе мне нужно обмануть систему, установив search_path внекоторые предопределенные схемы для каждого пользователя (роли).

---

Так что это те варианты / решения, которые я нашел до сих пор.Я согласен с необходимостью использовать search_path для точка 5 и жертвовать объединениями между таблицами / схемами в разных базах данных в целях конфиденциальности ( points 1 и 2 ), но я все же хотел бы знать, что является лучшим решением вышеуказанных проблем и каковы наилучшие способы их применения на практике.

С учетом сказанного явсе уши.

PS : Ссылки на информацию о том, как выполнить вышеупомянутое, также приветствуются.

Answer 1

В результате мы приняли следующее решение:

Точка 1 :

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

Точка 2 :

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

Примечание: PostgreSQL использует многоуровневые разрешения, что означает, что даже если база данных принадлежит кому-то, таблицы могут принадлежатькто-то еще.

Точка 3 :

Может быть сделано с С ГРАНТОВЫМ ВАРИАНТОМ .

Точка 4 :

Нет автоматизированного способа сделать это.Единственный способ убедиться в этом - ограничить «публичный» доступ ко всем существующим базам данных.

Точка 5 :

Использование search_path на каждомОсновой для пользователя является единственный способ сделать это, используя несколько пользователей для доступа к другой схеме (при необходимости).Очевидно, существует проблема, состоящая в том, что приложение, не знающее схему, не может «достичь» другой схемы, если не существует пользователя с соответствующим search_path .