Что такое 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
Схема (shema) в базе данных Oracle
Под термином схема в базе данных Oracle понимается — созданная учетная запись пользователя и объекты, которые ей принадлежат (например, индексы, триггеры, хранимые процедуры).
Посмотреть имеющиеся схемы в базе данных:
SQL> set pagesize 0; SQL> select username from dba_users order by 1; Создать новую схему в базе данных
SQL> CREATE USER scott IDENTIFIED BY tiger; Создать новую схему с явным указанием расположения, где должны храниться данные и индексы.
SQL> CREATE USER scott IDENTIFIED BY tiger DEFAULT TABLESPACE MY_DATA TEMPORARY TABLESPACE MY_TEMP ACCOUNT UNLOCK; Делегировать пользователю возможность подключаться к базе и работать с ней
SQL> grant connect, resource to scott Удалить схему можно следующей командой:
SQL> drop user scott cascade; Разблокировать схему, можно командой:
SQL> alter user scott account unlock; А поменять пароль
SQL> alter user system identified by NewPassword; Tags: Oracle Database, shemas
 |
 |
 |
Oracle DBA
Собираем также материалы по: SQL & PL/SQL
Лучше потратить какое-то количество времени, чтобы записать успешный опыт, чем потом повторно воспроизводить его по памяти.
Все материалы обновляются по мере нахождения лучших практик и апгрейда знаний. Если будут желающие добавлять свои знания или исправлять ошибки и неточности, пишите в телеграм чате. Если будет учавствовать больше людей, качество материалов будет улучшаться и обновляться быстрее. Ссылки на ваши профили в соц. сетях будут добавлены в статьях, в которых вы учавствуете.
Что такое схема в MySQL 1 мин для чтения
Данные в MySQL управляются в базах данных в виде таблиц, которые также состоят из строк и столбцов. Что такое схема? Схема отличается от баз данных, поскольку она не имеет всех привилегий, которые имеет база данных, она имеет только привилегии таблиц, строк и столбцов, которые определяют структуру базы данных.
В этой статье мы объясним, что такое схема, как она работает и каковы различия между схемой и базой данных.
Что такое схема
Схема базы данных — это архитектура базы данных, которая содержит информацию о шаблоне того, как данные должны быть помещены в таблицу, но должно быть ясно, что схема не имеет связи с самими данными, она просто сообщает возможные способы, которыми данные должны быть помещены в базу данных. Мы можем определить схему как структуру любой базы данных, которая сообщает нам о представлении таблицы, она также определяет количество строк, столбцов таблицы, первичные и внешние ключи, связанные с таблицами, а также определяет типы данных данных, которые нужно вставить в таблицы.
В основном в компаниях администраторы баз данных несут ответственность за предоставление надлежащей схемы для любой базы данных, в соответствии с которой разработчики баз данных разрабатывают базы данных.
Сравнение базы данных и схемы
| База данных | Схема |
|---|---|
| Хранит данные в таблицах | Обеспечивает логическое представление базы данных на основе таблиц |
| DML (язык модификации данных) используется для управления данными в базе данных. | DDL (язык определения данных) используется для управления представлением таблиц. |
| Данные можно редактировать в любое время | Модификации не поддерживаются |
| Он включает таблицы, схемы и все другие ограничения базы данных. | Он включает только структуры таблиц и привилегии, относящиеся к таблицам. |
| Занимает память на сервере | Не занимает памяти |
Читать Мастер-класс SQL: 10 популярных запросов для эффективной работы с базами данных
Какие бывают типы схем
Схемы можно разделить на два типа в зависимости от их функций, как показано на диаграмме ниже.
Физическая схема: это тип схемы, которую могут просматривать пользователи, она касается методов хранения данных и того, как они могут быть представлены в базе данных.
Логическая схема: это тип схемы, который рассказывает нам о концепции, лежащей в основе создания базы данных, он объясняет формирование таблиц, взаимосвязь таблиц друг с другом в базе данных и ключи, используемые в таблицах, которые могут быть первичный ключ, а также внешний ключ. Предположим вышеупомянутый пример «school_record_of_students», теперь он определяет количество строк и столбцов таблицы, а также связывает его с другими таблицами, скажем, «record_of_grade_2_students» с помощью первичных и внешних ключей.
Как схема работает в MySQL
Мы попытаемся создать базу данных с именем «company_abc» и схему с именем «school_abc», мы создадим таблицы и попытаемся вставить данные в обе таблицы и наблюдать за результатами, но перед созданием таблиц мы создадим база данных как
CREATE DATABASE company_abc;
Используйте эту базу данных для создания таблицы:
USE company_abc;
Создайте таблицу и назовите ее «employee_data».
CREATE TABLE employees_data (employee_id INT, employee_name VARCHAR(50), employee_age INT);
Вставьте данные в таблицу:
INSERT INTO student_data VALUE (1, “Andrey”, 25);
Чтобы отобразить таблицу:
SELECT * FROM employees_data;
Точно так же мы создадим схему school_abc:
CREATE SCHEMA school_abc;
Используйте только что созданную схему:
USE school_abc;
Создайте таблицу в схеме school_abc,
CREATE TABLE student_data (student_id INT, student_name VARCHAR(50), student_age INT);
Теперь вставляем данные в таблицу:
INSERT INTO student_data VALUE (1, “Maxim”, 16);
Чтобы отобразить таблицу:
SELECT * FROM student_data;
Чтобы показать базы данных.
SHOW databases;
Мы можем заметить, что в MySQL не только схема создается и отображается так же, как была создана база данных, но также таблица была создана как в схеме, так и в базе данных.
Читать Как использовать Sysbench для тестирования производительности Linux
Заключение
Схема — это структура, которая может помочь разработчикам в создании множества баз данных по единой схеме. В этой статье мы узнали, что схема является логическим представлением базы данных, и она отличается от базы данных, поскольку она не занимает места, тогда как база данных занимает некоторое пространство на сервере, но с помощью примеров мы вывели приводит к тому, что в MySQL схема является просто синонимом базы данных и может выполнять те же функции, что и база данных.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
5.7. Схемы
Кластер баз данных PostgreSQL содержит один или несколько именованных экземпляров баз. На уровне кластера создаются пользователи и группы, но данные могут относиться только к базам данных. При этом в рамках одного подключения к серверу можно обращаться к данным только одной базы данных, указанной при установлении соединения.
Замечание: Пользователи кластера не обязательно будут иметь доступ ко всем базам данным этого кластера. То, что пользователи создаются на уровне кластера, означает только, что в нём не может быть двух пользователей joe в разных базах данных, хотя система позволяет ограничить доступ joe только некоторыми базами данных.
База данных содержит одну или несколько именованных схем, которые в свою очередь содержат таблицы. Схемы также содержат именованные объекты других видов, включая типы данных, функции и операторы. Одно и то же имя объекта можно свободно использовать в разных схемах, например и schema1, и myschema могут содержать таблицы с именем mytable. В отличие от баз данных, схемы не ограничивают доступ к данным: пользователь может обращаться к объектам в любой схеме текущей базы данных, если ему назначены соответствующие права.
Есть несколько возможных объяснений, для чего стоит применять схемы:
Чтобы одну базу данных могли использовать несколько пользователей, независимо друг от друга.
Чтобы объединить объекты базы данных в логические группы для облегчения управления ими.
Схемы в некоторым смысле подобны каталогам в операционной системе, но они не могут быть вложенными.
5.7.1. Создание схемы
Для создания схемы используется команда CREATE SCHEMA. При этом вы определяете имя схемы по своему выбору, например так:
CREATE SCHEMA myschema;
Чтобы создать объекты в схеме или обратиться к ним, указывайте полное имя, состоящее из имён схемы и объекта, разделённых точкой:
схема.таблица
Этот синтаксис работает везде, где ожидается имя таблицы, включая команды модификации таблицы и команды обработки данных, обсуждаемые в следующих главах. (Для краткости мы будем говорить только о таблицах, но всё это распространяется и на другие типы именованных объектов, например, типы и функции.)
Есть ещё более общий синтаксис
база_данных.схема.таблица
но в настоящее время он поддерживается только для формального соответствия стандарту SQL. Если вы указываете базу данных, это может быть только база данных, к которой вы подключены.
Таким образом, создать таблицу в новой схеме можно так:
CREATE TABLE myschema.mytable ( . );
Чтобы удалить пустую схему (не содержащую объектов), выполните:
DROP SCHEMA myschema;
Удалить схему со всеми содержащимися в ней объектами можно так:
DROP SCHEMA myschema CASCADE;
Стоящий за этим общий механизм описан в Разделе 5.12.
Часто бывает нужно создать схему, владельцем которой будет другой пользователь (это один из способов ограничения пользователей пространствами имён). Сделать это можно так:
CREATE SCHEMA имя_схемы AUTHORIZATION имя_пользователя;
Вы даже можете опустить имя схемы, в этом случае именем схемы станет имя пользователя. Как это можно применять, описано в Подразделе 5.7.6.
Схемы с именами, начинающимися с pg_, являются системными; пользователям не разрешено использовать такие имена.
5.7.2. Схема public
До этого мы создавали таблицы, не указывая никакие имена схем. По умолчанию такие таблицы (и другие объекты) автоматически помещаются в схему «public» . Она содержится во всех создаваемых базах данных. Таким образом, команда:
CREATE TABLE products ( . );
CREATE TABLE public.products ( . );
5.7.3. Путь поиска схемы
Везде писать полные имена утомительно, и часто всё равно лучше не привязывать приложения к конкретной схеме. Поэтому к таблицам обычно обращаются по неполному имени, состоящему просто из имени таблицы. Система определяет, какая именно таблица подразумевается, используя путь поиска, который представляет собой список просматриваемых схем. Подразумеваемой таблицей считается первая подходящая таблица, найденная в схемах пути. Если подходящая таблица не найдена, возникает ошибка, даже если таблица с таким именем есть в других схемах базы данных.
Первая схема в пути поиска называется текущей. Эта схема будет использоваться не только при поиске, но и при создании объектов — она будет включать таблицы, созданные командой 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.7.4. Схемы и права
По умолчанию пользователь не может обращаться к объектам в чужих схемах. Чтобы изменить это, владелец схемы должен дать пользователю право USAGE для данной схемы. Чтобы пользователи могли использовать объекты схемы, может понадобиться назначить дополнительные права на уровне объектов.
Пользователю также можно разрешить создавать объекты в не принадлежащей ему схеме. Для этого ему нужно дать право CREATE в требуемой схеме. Заметьте, что по умолчанию все имеют права CREATE и USAGE в схеме public. Благодаря этому все пользователи могут подключаться к заданной базе данных и создавать объекты в её схеме public. Если вас это не устраивает, вы можете отозвать это право:
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
(Первое слово «public» обозначает схему, а второе «public» подразумевает «все пользователи» . В первом случае это идентификатор, а во втором — ключевое слово, поэтому оно написано в разном регистре; вспомните рекомендации из Подраздела 4.1.1.)
5.7.5. Схема системного каталога
В дополнение к схеме public и схемам, создаваемым пользователями, любая база данных содержит схему pg_catalog, в которой находятся системные таблицы и все встроенные типы данных, функции и операторы. pg_catalog фактически всегда является частью пути поиска. Если даже эта схема не добавлена в путь явно, она неявно просматривается до всех схем, указанных в пути. Так обеспечивается доступность встроенных имён при любых условиях. Однако вы можете явным образом поместить pg_catalog в конец пути поиска, если вам нужно, чтобы пользовательские имена переопределяли встроенные.
Так как имена системных таблиц начинаются с pg_, такие имена лучше не использовать во избежание конфликта имён, возможного при появлении в будущем системной таблицы с тем же именем, что и ваша. (С путём поиска по умолчанию неполная ссылка будет воспринята как обращение к системной таблице.) Системные таблицы будут и дальше содержать в имени приставку pg_, так что они не будут конфликтовать с неполными именами пользовательских таблиц, если пользователи со своей стороны не будут использовать приставку pg_.
5.7.6. Шаблоны использования
Схемам можно найти множество применений. Вот лишь некоторые шаблоны их использования, рекомендуемые и легко реализуемые в конфигурации по умолчанию:
Если вы явно не создаёте какие-либо схемы, все пользователи будут неявно обращаться к схеме public. Таким образом система ведёт себя так, как если бы схем не было вообще. Эта конфигурация в основном рекомендуется, когда в базе данных есть всего один или несколько сотрудничающих пользователей. Она также позволяет легко мигрировать из среды, где схемы не поддерживаются.
Вы можете создать отдельные схемы для каждого пользователя, назвав их именами пользователей. Вспомните, путь поиска по умолчанию начинается с $user, что интерпретируется как имя пользователя. Таким образом, если у пользователя будет своя схема, по умолчанию он будет обращаться к ней.
Если вы реализуете этот подход, вы, возможно, также захотите запретить доступ к схеме public (или даже удалить её), чтобы пользователи не выходили за рамки своих схем.
5.7.7. Переносимость
Стандарт SQL не поддерживает обращение в одной схеме к разным объектам, принадлежащим разным пользователям. Более того, в ряде реализаций СУБД нельзя создавать схемы с именем, отличным от имени владельца. На практике, в СУБД, реализующих только базовую поддержку схем согласно стандарту, концепции пользователя и схемы очень близки. Таким образом, многие пользователи полагают, что полное имя на самом деле образуется как имя_пользователя.таблица. И именно так будет вести себя PostgreSQL , если вы создадите схемы для каждого пользователя.
В стандарте SQL нет и понятия схемы public. Для максимального соответствия стандарту использовать схему public не следует (и возможно, лучше даже удалить её).
Конечно, есть СУБД, в которых вообще не реализованы схемы или пространства имён поддерживают (возможно, с ограничениями) обращения к другим базам данных. Если вам потребуется работать с этими системами, максимальной переносимости вы достигнете, вообще не используя схемы.
| Пред. | Начало | След. |
| Права | Уровень выше | Наследование |