Как скрыть строку подключения в демилитаризованной зоне

На нижнем уровне это в основном сводится к "Вам, может абсолютно сказать, что у Вас нет совместно используемых данных?" В отличие от mysql, база данных является абсолютной границей в postgresql. Вы не можете SELECT zip_code FROM common.city_zip WHERE city=... если Вы идете с отдельными базами данных (по крайней мере, не без dblink).

Если у Вас есть какие-либо совместно используемые данные вообще, "схема" postgresql подобна тому, что mysql называет "базой данных". Вы можете CREATE SCHEMA clienta; CREATE TABLE clienta.customer (...);. Вы создали бы схему для каждого клиента, что у пользователя клиента будет их схема сначала в их пути поиска, и разрешения были бы даны так, чтобы у пользователя Клиента A был доступ к clienta и public схемы (и их таблицы).

Ваша проблема будет этим на верхнем уровне # клиентов, каждая таблица хранится как файл, поэтому идете ли Вы с одной базой данных на клиент, одной схемой на клиент, или используете что-то как ${client}_customer для Ваших имен таблиц Вы, вероятно, столкнетесь с пределами filedescriptor с 10k клиентами, даже если у Вас только была одна таблица на клиент (плюс одно filedescriptor для каждого подключения). Конечно, можно скорректировать максимальное количество ядра дескрипторов файлов на лету с помощью sysctl, но предел для каждого процесса (ulimit) потребует перезапуска postgresql при установке его слишком низко в первый раз вокруг.

Альтернатива должна иметь "одну большую таблицу" с клиентским столбцом, который определяет, какой клиент, которому принадлежит строка (идеально, именем пользователя, если у Вас есть один пользователь на клиент, это делает материал ниже НАМНОГО более легкого). Не предоставляя доступа вообще к этой таблице клиентами, можно создать определенные для клиента представления (или использование session_user идентифицировать текущий клиент). Обновления не могут быть сделаны непосредственно посредством представления, все же. Необходимо было бы определить функции для вставления/обновления/удаления на таблице (один набор функций на клиент или иначе использование session_user) с использованием функций SECURITY DEFINER выполниться как специальный пользователь с разрешением вставить/обновить/удалить на таблицах (примечание: session_user используется потому что user и current_user основаны на текущем контексте, и в функции УСТРОЙСТВА ОПРЕДЕЛЕНИЯ БЕЗОПАСНОСТИ это всегда было бы пользователем, который определил функцию).

Мудрый производительностью, вне проблемы fd, я честно не знаю то, что произошло бы с 10 000 баз данных в postgresql, по сравнению с наличием одной большой таблицы с ценностью 10 000 клиентов данных в ней. Надлежащий индексный дизайн должен помешать большой таблице быть не спешащий запрос.

Я скажу, что пошел с отдельными базами данных для каждого клиента сюда (мы добавляем серверы для хранения системы применимой, смещая клиентские базы данных к новым серверам по мере необходимости, таким образом, мы никогда не будем добираться до 10k баз данных по одному серверу). Я должен был восстановить данные отдельных клиентов из резервных копий для отладки или из-за пользовательской ошибки регулярно, что-то, что было бы абсолютным кошмаром на "одной большой таблице" дизайн. Кроме того, если Вы намереваетесь продать настройку своего продукта Вашим клиентам, "одна большая таблица" дизайн могла бы закончить тем, что создавала помехи Вам до способности настроить модель данных.