Что такое схема в postgresql
Кластер баз данных Postgres Pro содержит один или несколько именованных экземпляров баз. На уровне кластера создаются пользователи и группы, но данные могут относиться только к базам данных. При этом в рамках одного подключения к серверу можно обращаться к данным только одной базы данных, указанной при установлении соединения.
Примечание
Пользователи кластера не обязательно будут иметь доступ ко всем базам данных этого кластера. То, что пользователи создаются на уровне кластера, означает только, что в нём не может быть двух пользователей joe в разных базах данных, хотя система позволяет ограничить доступ joe только некоторыми базами данных.
База данных содержит одну или несколько именованных схем, которые в свою очередь содержат таблицы. Схемы также содержат именованные объекты других видов, включая типы данных, функции и операторы. Одно и то же имя объекта можно свободно использовать в разных схемах, например и schema1 , и myschema могут содержать таблицы с именем mytable . В отличие от баз данных, схемы не ограничивают доступ к данным: пользователь может обращаться к объектам в любой схеме текущей базы данных, если ему назначены соответствующие права.
Есть несколько возможных объяснений, для чего стоит применять схемы:
Чтобы одну базу данных могли использовать несколько пользователей, независимо друг от друга.
Чтобы объединить объекты базы данных в логические группы для облегчения управления ими.
Схемы в некоторым смысле подобны каталогам в операционной системе, но они не могут быть вложенными.
5.8.1. Создание схемы
Для создания схемы используется команда CREATE SCHEMA . При этом вы определяете имя схемы по своему выбору, например так:
CREATE SCHEMA myschema;
Чтобы создать объекты в схеме или обратиться к ним, указывайте полное имя, состоящее из имён схемы и объекта, разделённых точкой:
схема.таблица
Этот синтаксис работает везде, где ожидается имя таблицы, включая команды модификации таблицы и команды обработки данных, обсуждаемые в следующих главах. (Для краткости мы будем говорить только о таблицах, но всё это распространяется и на другие типы именованных объектов, например, типы и функции.)
Есть ещё более общий синтаксис
база_данных.схема.таблица
но в настоящее время он поддерживается только для формального соответствия стандарту SQL. Если вы указываете базу данных, это может быть только база данных, к которой вы подключены.
Таким образом, создать таблицу в новой схеме можно так:
CREATE TABLE myschema.mytable ( . );
Чтобы удалить пустую схему (не содержащую объектов), выполните:
DROP SCHEMA myschema;
Удалить схему со всеми содержащимися в ней объектами можно так:
DROP SCHEMA myschema CASCADE;
Стоящий за этим общий механизм описан в Разделе 5.13.
Часто бывает нужно создать схему, владельцем которой будет другой пользователь (это один из способов ограничения пользователей пространствами имён). Сделать это можно так:
CREATE SCHEMAимя_схемыAUTHORIZATIONимя_пользователя;
Вы даже можете опустить имя схемы, в этом случае именем схемы станет имя пользователя. Как это можно применять, описано в Подразделе 5.8.6.
Схемы с именами, начинающимися с pg_ , являются системными; пользователям не разрешено использовать такие имена.
5.8.2. Схема public
До этого мы создавали таблицы, не указывая никакие имена схем. По умолчанию такие таблицы (и другие объекты) автоматически помещаются в схему « public » . Она содержится во всех создаваемых базах данных. Таким образом, команда:
CREATE TABLE products ( . );
CREATE TABLE public.products ( . );
5.8.3. Путь поиска схемы
Везде писать полные имена утомительно, и часто всё равно лучше не привязывать приложения к конкретной схеме. Поэтому к таблицам обычно обращаются по неполному имени, состоящему просто из имени таблицы. Система определяет, какая именно таблица подразумевается, используя путь поиска, который представляет собой список просматриваемых схем. Подразумеваемой таблицей считается первая подходящая таблица, найденная в схемах пути. Если подходящая таблица не найдена, возникает ошибка, даже если таблица с таким именем есть в других схемах базы данных.
Возможность создавать одноимённые объекты в разных схемах усложняет написание запросов, которые должны всегда обращаться к конкретным объектам. Это также потенциально позволяет пользователям влиять на поведение запросов других пользователей, злонамеренно или случайно. Ввиду преобладания неполных имён в запросах и их использования внутри PostgreSQL , добавить схему в search_path — по сути значит доверять всем пользователям, имеющим право CREATE в этой схеме. Когда вы выполняете обычный запрос, злонамеренный пользователь может создать объекты в схеме, включённой в ваш путь поиска, и таким образом перехватывать управление и выполнять произвольные функции SQL как если бы их выполняли вы.
Первая схема в пути поиска называется текущей. Эта схема будет использоваться не только при поиске, но и при создании объектов — она будет включать таблицы, созданные командой CREATE TABLE без указания схемы.
Чтобы узнать текущий тип поиска, выполните следующую команду:
SHOW search_path;
В конфигурации по умолчанию она возвращает:
search_path -------------- "$user", public
Первый элемент ссылается на схему с именем текущего пользователя. Если такой схемы не существует, ссылка на неё игнорируется. Второй элемент ссылается на схему public, которую мы уже видели.
Первая существующая схема в пути поиска также считается схемой по умолчанию для новых объектов. Именно поэтому по умолчанию объекты создаются в схеме public. При указании неполной ссылки на объект в любом контексте (при модификации таблиц, изменении данных или в запросах) система просматривает путь поиска, пока не найдёт соответствующий объект. Таким образом, в конфигурации по умолчанию неполные имена могут относиться только к объектам в схеме public.
Чтобы добавить в путь нашу новую схему, мы выполняем:
SET search_path TO myschema,public;
(Мы опускаем компонент $user , так как здесь в нём нет необходимости.) Теперь мы можем обращаться к таблице без указания схемы:
DROP TABLE mytable;
И так как myschema — первый элемент в пути, новые объекты будут по умолчанию создаваться в этой схеме.
Мы можем также написать:
SET search_path TO myschema;
Тогда мы больше не сможем обращаться к схеме public, не написав полное имя объекта. Единственное, что отличает схему public от других, это то, что она существует по умолчанию, хотя её так же можно удалить.
В Разделе 9.25 вы узнаете, как ещё можно манипулировать путём поиска схем.
Как и для имён таблиц, путь поиска аналогично работает для имён типов данных, имён функций и имён операторов. Имена типов данных и функций можно записать в полном виде так же, как и имена таблиц. Если же вам нужно использовать в выражении полное имя оператора, для этого есть специальный способ — вы должны написать:
OPERATOR(схема.оператор)
Такая запись необходима для избежания синтаксической неоднозначности. Пример такого выражения:
SELECT 3 OPERATOR(pg_catalog.+) 4;
На практике пользователи часто полагаются на путь поиска, чтобы не приходилось писать такие замысловатые конструкции.
5.8.4. Схемы и права
По умолчанию пользователь не может обращаться к объектам в чужих схемах. Чтобы изменить это, владелец схемы должен дать пользователю право USAGE для данной схемы. Чтобы пользователи могли использовать объекты схемы, может понадобиться назначить дополнительные права на уровне объектов.
Пользователю также можно разрешить создавать объекты в схеме, не принадлежащей ему. Для этого ему нужно дать право CREATE в требуемой схеме. Заметьте, что по умолчанию все имеют права CREATE и USAGE в схеме public . Благодаря этому все пользователи могут подключаться к заданной базе данных и создавать объекты в её схеме public . Некоторые шаблоны использования требуют запретить это:
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
(Первое слово « public » обозначает схему, а второе означает « каждый пользователь » . В первом случае это идентификатор, а во втором — ключевое слово, поэтому они написаны в разном регистре; вспомните указания из Подраздела 4.1.1.)
5.8.5. Схема системного каталога
В дополнение к схеме public и схемам, создаваемым пользователями, любая база данных содержит схему pg_catalog , в которой находятся системные таблицы и все встроенные типы данных, функции и операторы. pg_catalog фактически всегда является частью пути поиска. Если даже эта схема не добавлена в путь явно, она неявно просматривается до всех схем, указанных в пути. Так обеспечивается доступность встроенных имён при любых условиях. Однако вы можете явным образом поместить pg_catalog в конец пути поиска, если вам нужно, чтобы пользовательские имена переопределяли встроенные.
Так как имена системных таблиц начинаются с pg_ , такие имена лучше не использовать во избежание конфликта имён, возможного при появлении в будущем системной таблицы с тем же именем, что и ваша. (С путём поиска по умолчанию неполная ссылка будет воспринята как обращение к системной таблице.) Системные таблицы будут и дальше содержать в имени приставку pg_ , так что они не будут конфликтовать с неполными именами пользовательских таблиц, если пользователи со своей стороны не будут использовать приставку pg_ .
5.8.6. Шаблоны использования
Схемам можно найти множество применений. Хотя есть несколько шаблонов использования, легко поддерживаемых стандартной конфигурацией, только один из них достаточно безопасен, когда одни пользователи базы данных не доверяют другим:
Ограничить обычных пользователей личными схемами. Для реализации этого подхода выполните REVOKE CREATE ON SCHEMA public FROM PUBLIC и создайте для каждого пользователя схему с его именем. Если затрагиваемые пользователи подключались к базе ранее, проведите аудит схемы на предмет наличия таких же имён, как в схеме pg_catalog . Вспомните, что путь поиска по умолчанию начинается со значения $user , которое разрешается в имя пользователя. Таким образом, если у всех пользователей будет отдельная схема, они по умолчанию будут обращаться к собственным схемам.
Удалить схему public из пути поиска по умолчанию для каждого пользователя с помощью команды ALTER ROLE пользователь SET search_path = «$user» . Все сохранят возможность создавать объекты в общедоступной схеме, но обращаться к ним будут только по полным именам. Хотя обращение к таблицам по полным именам вполне безопасно, вызовы функций в схеме public будут небезопасными или ненадёжными. Кроме того, пользователь, имеющий право CREATEROLE , может отменить это назначение и выполнять произвольные запросы от имени пользователей, полагающихся на этот путь. Если вы создаёте функции или расширения в схеме public или даёте пользователям право CREATEROLE , но не хотите, чтобы они стали практически суперпользователями, вам нужно использовать первый шаблон.
Удалить схему public из пути поиска search_path в postgresql.conf . Это будет иметь такое же влияние на пользователей, что и предыдущий шаблон. В дополнение к его особенностям относительно функций и права CREATEROLE , данный шаблон подразумевает также доверие к владельцам базам данных, как к имеющим право CREATEROLE . Если вы создаёте функции или расширения в схеме public, даёте пользователям права CREATEROLE , CREATEDB или делаете их владельцами отдельных баз данных, но не хотите, чтобы они стали практически суперпользователями, вам нужно использовать первый шаблон.
При любом подходе, устанавливая совместно используемые приложения (таблицы, которые нужны всем, дополнительные функции сторонних разработчиков и т. д.), помещайте их в отдельные схемы. Не забудьте дать другим пользователям права для доступа к этим схемам. Тогда пользователи смогут обращаться к этим дополнительным объектам по полному имени или при желании добавят эти схемы в свои пути поиска.
5.8.7. Переносимость
Стандарт SQL не поддерживает обращение в одной схеме к разным объектам, принадлежащим разным пользователям. Более того, в ряде реализаций СУБД нельзя создавать схемы с именем, отличным от имени владельца. На практике, в СУБД, реализующих только базовую поддержку схем согласно стандарту, концепции пользователя и схемы очень близки. Таким образом, многие пользователи полагают, что полное имя на самом деле образуется как имя_пользователя . имя_таблицы . И именно так будет вести себя Postgres Pro , если вы создадите схемы для каждого пользователя.
В стандарте SQL нет и понятия схемы public . Для максимального соответствия стандарту использовать схему public не следует.
Конечно, есть СУБД, в которых вообще не реализованы схемы или пространства имён поддерживают (возможно, с ограничениями) обращения к другим базам данных. Если вам потребуется работать с этими системами, максимальной переносимости вы достигнете, вообще не используя схемы.
| Пред. | Наверх | След. |
| 5.7. Политики защиты строк | Начало | 5.9. Наследование |
В Postgresql схема: зачем нужна и как я её могу использовать в своих проектах?
Здравствуйте!
Ещё не работал с Postgresql, и не знаю, как он работает, в чем он лучше, а в чем хуже других СУБД.
Недавно начал изучить Postgresql (надо было реализовать один проект и знакомые предложили Postgresql. а до этого работал с MySQL, Oracle)
В проекте такая структура, Интернет магазин(Покупатель, продавец, товары, склады, заказы и т.д) Структура интернет магазина чуть сложнее. и Есть одна задача:
— Интернет магазина можем продавать в других городах. А БД нужно реализовать так чтобы мы могли дать доступ клиенту, и он работал только со своими городом, и при этом все данные будет в одном БД но не должно смешиваться. с остальными городами.
Я прочитал о схема в Postgresql, пока не очень понял в чем фишка схем в Postgresql но я думаю. можно использовать схема Postgresql в моих проектах? и как лучше реализовать?
- Вопрос задан более трёх лет назад
- 8085 просмотров
5 комментариев
Средний 5 комментариев
Уточните зачем вам схемы впринципе нужны для мульти-магазинов на одной БД?
Если вам требуется подкорректировать проект БД, то нужно полнее описать задачу
Дилик Пулатов @dilikpulatov Автор вопроса
sim3x, я думал, может стоит использовать схему для разделение данные клиентов которые покупали наш проект? Мне просто нужно как-то проще разделить данные клиента но при этом они все должны быт в одном БД. Думаю вы поняли о чем я
Если клиент покупает магазин на вашем хостинге, то можно придумать как присобачить схему
Но удобнее использовать миграции
Если на хосте клиента — то вообще никак
Используйте механизм миграций в вашем бекенд фреймворке
Думаю вы поняли о чем я
Дилик Пулатов @dilikpulatov Автор вопроса
sim3x, Грубо говоря клиент покупает только доступ. Все данные будет только у меня на сервере.
О миграции пока не знаю, но я стараюсь чтобы все данные было в одном БД, потому что при добавление нового функции или исправление багов. ну вообщем при изменение мне не придется гулять в каждому БД клиента
Физическое разнесение клиентов по своим БД имеет свои плюсы
у вообщем при изменение мне не придется гулять в каждому БД клиента
именно для автоматизации такого рода вещей и изобрели миграции
грубо говоря клиент покупает только доступ. Все данные будет только у меня на сервере.
тогда схемы постгреса вам не нужны
Для общего развития можно почитать документацию по ним, но не более
Решения вопроса 0
Ответы на вопрос 1
PostgreSQL DBA
В оракле схем разве нет.
schema — дополнительный уровень структуризации объектов. Как namespace в программировании. И, к слову, входит в стандарт SQL.
Вы можете сделать таблицы:
user_subscriptions
user_orders
user_favorites
Вы можете сделать
user.subscriptions
user.orders
user.favorites
И в этом нет никакой разницы для СУБД. Но может быть удобно разработчику оперировать не с сотней таблиц одним списком, десятки из которых с одинаковыми префиксами (т.к. относятся к своим сущностям), а отдельные схемы по сущностях.
Пилить же одну таблицу на несколько смысла при этом не так много, зато добавляется хлопот.
Если вы хотите давать прямой доступ пользователю к базе — то зачем? Не надо так делать в разделяемой среде. Любую СУБД можно положить каким-нибудь интересным запросом. А в то что люди временами будут писать интересные и сильно творческие запросы — по опыту DBA вам гарантирую. Иногда такого наворотят. 0,5тб временный файлов одним запросом, например. Или сожрать 30гб RAM и увести базу в аварийный рестарт от OOM.
SQL-Ex blog
Схемы в PostgreSQL. Изучаем PostgreSQL вместе с Grant Fritchey
Добавил Sergey Moiseenko on Среда, 9 августа. 2023
Важным аспектом при построении и обслуживании базы данных является организация объектов в вашей базе данных. У вас могут быть таблицы, которые обслуживают различные направления, например, схема для операций с хранилищами данных и схема для продаж. Некоторым логинам может потребоваться доступ к определенным таблицам, но не к остальным. Вы можете захотеть изолировать одно множество объектов в базе данных от других множеств объектов. Все это, и многое другое, может быть выполнено при помощи схем в базе данных, и PostgreSQL поддерживает использование схемы именно для этих типов функциональности.
В тестовой базе данных, которую я использую для примеров к этой серии статей, была создана пара схем с таблицами в каждой из них. Вы можете посмотреть на эту базу данных в скрипте CreateDatabase.sql. Остальной код для этой статьи находится в папке 08_Schema.
Обслуживание схемы
Схема используется в первую очередь как механизм организации вашей базы данных. Далее вы можете перейти к использованию схемы для проектирования безопасности, управления доступом и тем, что пользователи могут видеть и делать в вашей базе данных. При создании пустой базы данных она будет включать схему по умолчанию public.
Когда вы создаете объект типа таблицы, он автоматически приписывается схеме по умолчанию, если не задано обратное. По умолчанию все логины в базе данных имеют доступ к схеме public (PostgreSQL 15 изменил это поведение по умолчанию, поэтому теперь пользователи не имеют прав на создание объектов в схеме public). Помимо этого поведения по умолчанию, схема public является просто одной из схем в базе данных, и большинство функций и правил, которые будут далее обсуждаться, применимы к этой схеме.
Для начала создадим свои собственные схемы. Синтаксис очень простой:
CREATE SCHEMA mytestschema;
Этот оператор создает схему с именем mytestschema. Для создания таблицы в этой схеме вы просто используете имя таблицы из двух частей (имя_схемы.имя_таблицы) в операторе CREATE TABLE, например, так:
create table mytestschema.testtable
(id int,
somevalue varchar(50));
Так же и при любых запросах:
select id from mytestschema.testtable;
Вы можете думать о схеме как о владельце таблицы (владелец схемы технически является владельцем таблицы). Указание владельца повсюду в вашем коде является гарантией, что ничего неожиданного не произойдет. Поскольку, когда вы начинаете использовать схему, то можете давать объектам имена, которые существуют в других схемах. Давать уникальные имена — это хорошая практика, но иногда одно и то же имя в различных схемах является лучшим вариантом):
create schema secondschema:
create table secondschema.testtable
(insertdate date,
someothervalue varchar(20));
Это совершенно допустимо. Если бы я написал то, что я считаю плохим кодом, например:
select * from testtable;
то, вероятно, получил бы следующую ошибку:
ERROR: relation «testtable» does not exist
(отношение «testtable» не существует)
LINE 2: select * from testtable;
Сначала кажется, что ошибка возникает потому, что PostgreSQL не может решить, из какой из двух таблиц брать данные. Скорее, потому, что логины имеют схему по умолчанию. Когда я выполняю запрос, подобный последнему, без указания схемы, где находится таблица, PostgreSQL смотрит путь по умолчанию. Если таблицы там нет, значит ее не существует. Это справедливо, хотя у меня есть две таблицы с этим именем. PostgreSQL не проверяет другие схемы «на всякий случай».
Ниже в этой статье я расскажу, как управлять схемами по умолчанию.
Если схема пустая, вы можете ее удалить:
drop table if exists secondschema.testtable;
drop schema if exists secondschema;
Если я сначала не удалю таблицу, возникнет ошибка:
SQL Error [2BP01]: ERROR: cannot drop schema mytestschema because other objects depend on it
(нельзя удалить схему mytestschema, поскольку от нее зависят другие объекты)
Detail: table mytestschema.testtable depends on schema mytestschema
(таблица mytestschema.testtable зависит от схемы mytestschema)
Hint: Use DROP . CASCADE to drop the dependent objects too.
(используйте DROP . CASCADE для удаления также и зависимых объектов)
В сообщении об ошибке дается совет, как исправить ситуацию. Я мог бы переписать запрос следующим образом:
drop schema if exists mytestschema cascade;
Плюс, что при этом будут удалены все таблицы, представления и т.д., присутствующие в данной схеме. Но есть и минус в том, что будут удалены все таблицы, представления и прочее без всяких предупреждений.
В каждой базе данных создается схема по умолчанию с именем public. Однако это только по умолчанию и, как в большинстве настроек по умолчанию, ее можно изменить. Фактически вы даже можете удалить схему public, если захотите. Я начал этот раздел с объяснения, как создать свою собственную схему, которой вы непосредственно управляете, в противоположность принимаемой по умолчанию.
Управление путями поиска по умолчанию
Помимо помощи в организации объектов вашей базы данных, схема помогает контролировать доступ к этим объектам. Я еще не углублялся в тему безопасности в этой серии и, вероятно, до нее еще далеко. Однако я немного расскажу о том, как схема помогает управлять безопасностью базы данных. (Мой коллега Ryan Booz недавно опубликовал статью на эту тему ).
В этом разделе я хочу более детально обсудить некоторые способы управления схемой по умолчанию.
В последнем примере предыдущего раздела я показал, что вы можете иметь дубликаты имен таблиц в разных схемах, но при этом вы должны указывать имя схемы для доступа к этим таблицам. Однако это не вся история.
На самом деле существует определенный список поиска для схемы, который вы можете увидеть, используя такой запрос:
show search_path;
Если вы ничего не меняли на сервере, то результаты по умолчанию будут такими:
Каждый пользователь имеет собственную схему, как в SQL Server. Это и есть схема $user, которую вы видите выше. Однако, если вы не указали схему, по умолчанию будет принята первая в списке поиска, public в данном случае. Мы можем добавить схему в список поиска для текущего подключения:
SET search_path TO radio,public;
Это не только добавит схему radio в search_path, но и изменит порядок в пути поиска, поэтому схема radio ищется до схемы public. Если вы выполните отключение, а потом подключитесь вновь, вы должны будете переустановить путь с помощью команды SET.
Если вы хотите сделать изменения пути принимаемыми по умолчанию, то можете использовать ALTER ROLE, чтобы установить для любой роли специфический путь поиска. Например:
ALTER ROLE scaryDba SET search_path = 'radio,public,$user';
Если вы хотите установить значение по умолчанию для сервера/кластера/базы данных, то можете изменить search_path в файле postgressql.cnf или использовать команду:
ALTER ROLE ALL SET search_path = '$user';
Это не будет иметь приоритета над индивидуальными установками путей, но сделает для каждого логина, который не имеет приоритетного пути поиска, необходимость указывать имя схемы при ссылках на любой объект. (Что, как уже отмечалось, является лучшей практикой.)
Владение и основные привилегии
Когда вы создаете схему, то можете определить владельца схемы, отличного от логина, который выполняет эту команду:
CREATE SCHEMA secureschema AUTHORIZATION radio_admin;
Схема, которую я еще не создал ранее, secureschema, будет создана с владельцем, являющимся ролью логина radio_admin (тоже еще не определенной, поскольку я еще не разбирался с безопасностью). Это будет гарантировать, что только логин radio_admin и, конечно, любая учетная запись, определенная как суперпользователь, смогут работать в этой схеме.
Вы можете также управлять поведением по схеме. Например, поскольку я установил независимую схему в этой базе данных и намереваюсь использовать ее в этой манере, я могу запретить доступ для всех логинов на создание объектов в схеме public (это необходимо только в PostgreSQL 14 и ранее, в 15 разрешение на создание не предоставляется по умолчанию):
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
Здесь используется слово “public” в двух разных значениях. В первом, ‘public’, мы ссылаемся на схему с этим именем. Во втором, ‘PUBLIC’, мы говорим о роли, которая содержит всех пользователей в базе данных. Этот механизм призван гарантировать, что ничего случайно не будет помещено в схему public. Я бы сказал, что полезно следовать этой практике, если вы собираетесь использовать другие схемы, особенно, если вы используете их для обеспечения безопасности вашей базы данных.
Вы можете предоставить различные привилегии между схемой и пользователями так, чтобы данный пользователь мог читать данные из таблиц в схеме, но не мог модифицировать данные в таблицах (доступ только на чтение). Тем самым вы можете объединить данные разных типов в одной базе данных, но изолировать их при необходимости друг от друга. Это главная причина использования схем в базе данных.
Если вы не изолируете хранилище и доступ между схемами, то изначально не имеет большого смысла использовать какие-либо схемы помимо public. Однако большинство приложений имеет разнообразные уровни доступа, которыми он хотели бы управлять, и схемы предоставляют им подходящую реализацию этого типа безопасности. Если безопасность и не является проблемой, использование имен схем вместо размещения всех объектов в схеме public может быть выгодным также с точки зрения документирования.
Заключение
Схемы представляют собой контейнеры, которые позволяют сегментировать объекты и обеспечивать безопасность на более низком уровне, чем уровень базы данных. Использование схем, отличных от public, имеет хорошие преимущества. В PostgreSQL имеется несколько методов установки схемы по умолчанию, если ваши пользователи не любят использовать двойные имена.
Если вы знакомы со схемами в SQL Server, базовая функциональность схемы примерно та же, что и там. Однако есть дополнительная функциональность, подобно возможности управлять изменением списка поиска, которой обладает PostgreSQL.
Ссылки по теме
- Безопасность SQL Server — модель безопасности с использованием определяемых пользователем ролей
- Типы данных в PostgreSQL: изучаем PostgreSQL с Grant Fritchey
Что такое schema в БД?
Что такое schema в postgreSQL? Её надо создавать сразу после создания БД? Это логическое устройство таблиц, наполнения, прав и т.д. И тогда может быть много схем и они могут использовать общие таблицы?
Отслеживать
задан 14 окт 2020 в 13:42
575 2 2 серебряных знака 13 13 бронзовых знаков
@Мелкий писал ответ на этот вопрос тут qna.habr.com/answer?answer_id=1423551#answers_list_answer
14 окт 2020 в 14:49
и тут теперь будет
14 окт 2020 в 14:54
@Мелкий может ли в одной схеме быть таблица из другой?
14 окт 2020 в 18:38
@Venot таблица всегда относится к одной схеме. в другой схеме может быть другая таблица с тем же именем, что в первой и это будут разные таблицы
14 окт 2020 в 20:10
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Schemas are analogous to directories at the operating system level, except that schemas cannot be nested.
Схемы — это дополнительный уровень структурирования объектов базы. Похоже на директории в файловой системе или пространства имён ( namespace ) в программировании. Но не могут быть вложенными.
Пользуясь аналогией с файловой системой и вебом: есть файлы стилей CSS, какие-то JS. Ничто не мешает их все размещать в корневой директории веб-сервера. Но обычно их размещают всё-таки в поддиректориях для собственного удобства.
После создания новой базы у вас будет предопределённая схема public с правами для создания новых объектов для всех пользователей. Что делать дальше — решение разработчика схемы этой базы, проигнорировать схемы и размещать всё в public , структурировать как-либо по схемам, можно удалить public схему даже.
- users
- user_settings
- user_favorites
- blog_posts
- blog_comments
- users
- users.settings
- users.favorites
- blog.posts
- blog.comments
Самой базе без разницы. Схемы — это логический уровень, как названия таблиц.
Большинство проектов схемы не используют.
Права: у схем есть права create — кто может создавать новые объекты, и usage — кто может обращаться к объектам в той схеме. Поэтому может быть удобно для разработчиков сделать отдельную схему user_tmp и исключить её из бекапов, а в остальные схемы не давать прав create — тем самым форсируя, что таблицы приложения проходят через обычную принятую у вас процедуру миграций.
Для полноты картины: схемы public может и не быть, если она была удалена в базе, которая указанна в template опции create database