Схемы PostgreSQL - сценарий использования / пример

Question

Я прошу прощения за мой вопрос, похожий на новичка, но я новичок в PostgreSQl и схемах. Мне трудно понять назначение схем в PostgreSQL .. и вообще. Каковы возможные варианты использования схем?

В моей книге говорится, что схемы похожи на каталоги, которые нельзя вкладывать. Итак, я так понимаю, схемы - это средство для группировки таблиц в БД. В книге не рассматривается, как это реализовано, и не упоминаются возможные варианты использования, за исключением одного тривиального примера (следующий абзац).

Вариант использования преимуществ и возможностей # 1

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

Я не очень понимаю, почему у вас должно быть несколько таблиц с одинаковым именем для начала. Я бы подумал, что это крайне редкий случай, но документы приходят мне на ум, как будто схемы должны использоваться всеми. Мне кажется, что иметь несколько таблиц с одним и тем же именем - плохое управление проектами, а учёт такой плохой практики не выглядит ценным. В конце концов, вы просто позволяете создать беспорядок.

Единственный сценарий, который я могу придумать, где у вас могут быть конфликты имен таблиц, которые следует разрешить, это когда у вас есть класс, который изучает SQL, и школьный ИТ-администратор хочет, чтобы каждый учащийся мог создавать таблицы по своему вкусу. Конечно, у меня возникает вопрос: почему администратор просто не создает 1 дБ на каждого учащегося, а не 1 дБ на всех и 1 схему на каждого учащегося? Q1: Почему?

Какие еще варианты использования показывают преимущества схем?

РЕАЛИЗАЦИЯ - ИЛИ - ПРИРОДА

Я также запутался в реализации / природе схем.
Предположим, что у нас есть 1 БД, которая имеет 3 схемы. 1 схема на пользователя как таковая:
user1 = 'admin' - таблица A, таблица U, таблица J, таблица K,
user2 = 'joe ' ------ tableU, tableJ,
user3 = 'kate ----- tableU, tableK.

В приведенном выше примере я намерен, чтобы tableU было разделено между пользователями (через схему joe & schema kate). Они не должны получать свою собственную автономную копию таблицы, они должны иметь общий доступ к этой таблице. Этот тип использования имеет смысл для меня. Пользователи должны добавлять / изменять / потенциально удалять записи ... не добавлять / изменять / удалять таблицы. Однако я не уверен, что это возможно с помощью схем PostgreSQL. Q2: Если бы я захотел поделиться таблицей U, как я описал выше, получал ли каждый из них схему joe & schema kate, или я мог указать, что они не должны получать свою собственную копию и вместо этого просто делиться доступом к существующей таблице?

tableJ - это то же самое , что и tableK ... за исключением того, что Кейт не может использовать tableJ и Джо не может использовать tableK. Мне кажется, это является сущностью схем в соответствии с моим ограниченным пониманием схем. Q3: Какова цель создания копии таблицы для каждого пользователя? Эти 2 таблицы имеют одинаковую структуру (столбцы и ограничения), и создание пустой копии такой таблицы для каждого пользователя является пустой тратой пространства для хранения. Я также думаю, что было бы кошмаром, если бы у каждого пользователя была своя копия каждой таблицы. Мы будем выбрасывать ключевые понятия, такие как нормализация, в окно. Это было бы неразрешимым беспорядком. На мой взгляд, каждый пользователь должен добавлять / изменять / удалять записи в общей таблице в общей БД.

Я видел, как люди в моих поисках Google по схемам составляли отдельные схемы + таблицы для каждого онлайн-клиента на своем веб-сайте.У них около 100 000 схем. Q4: Что мне здесь не хватает?Это кажется крайним, если не сказать больше.Они должны добавлять записи в стандартную таблицу (таблицы) для каждого клиента, а не создавать схемы и таблицы для каждого клиента.Это только добавляет мне путаницы.

В любом случае, я надеюсь, что достаточно четко изложил ключевые моменты моей путаницы.

Я ищу следующее:
(1)Чтобы прояснить преимущества схем с помощью реалистичных примеров использования.
(2) Чтобы прояснить детали реализации схем.

---

РЕДАКТИРОВАТЬ v.3

Вариант потенциального использования # 2

Если я правильно понял Невилла К, онпредложить в качестве варианта использования:

1 БД, которая имеет 3 схемы.1 схема на пользователя как таковая (имя пользователя == имя_схемы в примере):
user1 = 'admin' - tableA, tableLogin, tblFin1, tblFin2, tblFin3, tblPrj1, tblPrj2, tblPrj3.
user2 = 'joe ' ------ tableLogin, tblFin1, tblFin2, tblFin3
user3 = 'kate ----- tableLogin, tblPrj1, tblPrj2, tblPrj3,

Здесь Джо работает в отделе финансов, а Кейт - руководитель проекта.Приложение, которое использует Джо, ограничено таблицами, связанными с финансами, приложение, которое использует Кейт, ограничено таблицами управления проектами.Это ограничение применяется посредством привязки имени пользователя к схеме, связанной с путем поиска (применяется на уровне БД).

Q5: Не будет ли такое же ограничение без схем?Какие таблицы доступны для какого приложения, зависит от того, какие таблицы были установлены для использования приложением во время создания приложения командой разработчиков.Нет?Или мы предполагаем, что мы используем готовые приложения, которые вы указываете на БД, и мы обеспокоены тем, что приложение не может в своих настройках быть ограниченным определенными таблицами (и это ограничение заблокировано паролем в готовом продукте)приложение)?

Потенциальный вариант использования # 3

Если я правильно понял Catcall, он предлагает в качестве варианта использования:

Сценарий, в котором вы хотите арендовать /арендовать услуги сервера базы данных, размещенного на 1 физической системе, нескольким клиентам, нуждающимся в обслуживании базы данных.Таким образом, возникает мультитенантный сценарий.На этом этапе вы можете выбрать:
(1) отдельную базу данных для каждого арендатора (клиента)
- более безопасную и удобную, но поддерживающую меньшее количество арендаторов на систему.
(2) одна общая база данных ссхема для каждого арендатора (клиента)
- Меньше защищен и немного менее удобен, но может поддерживать больше арендаторов на систему.

Потенциальный вариант использования # 4

Если я правильно понял Скотта Марлоу и Catcall, другой вариант использования будет:

Использование схем для выделения новогосодержание разработчиков в процессе разработки.Позже можно объединить работу с другой схемой.

Answer 1

Я видел, как люди в моих поисках Google по схемам составляли отдельные схемы + таблицы для каждого онлайн-клиента на своем сайте.У них около 100 000 схем.Q3: что мне здесь не хватает?Это кажется крайним, если не сказать больше.Они должны добавлять записи в стандартную таблицу (таблицы) для каждого клиента, а не создавать схемы и таблицы для каждого клиента.

Легко построить одну базу данных на каждого арендатора (клиента), что обеспечит вам максимальную изоляцию между арендаторами и простейшее аварийное восстановление.Но это относительно дорого.

Также легко построить одну схему для каждого арендатора.Есть меньшая степень изоляции между арендаторами.DBMS может поддерживать больше клиентов на сервер с одной схемой на клиента, чем с одной базой данных на клиента.Аварийное восстановление для одного арендатора сложнее, чем с одной базой данных на каждого арендатора.

Для общей схемы требуется, чтобы каждая строка имела идентификатор клиента.Аппаратное обеспечение и резервное копирование дешевле;аварийное восстановление для одного арендатора может стать настоящей сукой.(Чтобы восстановить данные для одного арендатора, необходимо восстановить несколько строк в каждой таблице. Производительность страдает для всех арендаторов, когда это происходит.) Изоляция сложнее.Поскольку арендаторы совместно используют таблицы, убедиться, что ни один из них не может получить доступ к данным других арендаторов, намного сложнее, чем с одной базой данных или одной схемой на каждого арендатора.

Поисковым термином для этого материала является "многопользовательский дизайн базы данных".SO также имеет мультитенантный тег .

Другим распространенным применением является группирование объектов базы данных, которые принадлежат друг другу.Например, если вы разрабатывали базу данных бухгалтерского учета, все объекты, которые реализуют функции «кредиторской задолженности», могут быть включены в схему «ap».Я также использую схемы для расширений PostgreSQL.В моей базе данных я установил расширение hstore в схеме "hst", расширение tablefunc в схеме "tbf" и т. Д.

Answer 2

Ответ Невилла К. отражает суть, но, возможно, немного кратко.

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

Кроме того, новые программисты также не ценят значение пространств имен. Оказывается, это, казалось бы, тривиальное преимущество, позволяющее нескольким объектам иметь одинаковые имена, не так уж тривиально. Только когда вы некоторое время работаете над более крупными проектами (с тысячами «объектов кода»: таблиц, представлений, индексов, хранимых процедур, доменов и т. Д.), Вы начинаете понимать, что преимущества пространств имен перевешивают их стоимость.

В более раннем возрасте (а не в PostgreSQL) я работал в компьютерном бюро с примерно 20 заказчиками, от 250 одновременных пользователей СУБД до одного, каждый через частные арендованные телефонные линии. (Это было до появления Интернета.) У каждого клиента была своя собственная схема с пользователем-администратором (роль), который мог создавать и удалять других пользователей по мере прихода и ухода сотрудников, предоставлять и отзывать привилегии, выполнять ограниченный объем работы по определению данных и импорт / экспорт в собственной схеме. Как разработчик я должен был использовать схемы, потому что был только один экземпляр СУБД и одна база данных. Так что ... если вышеупомянутое не убедительно, вы можете сказать, что схемы соответствуют стандарту SQL (по историческим причинам), поэтому PostgreSQL имеет поддержку схем.

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

Answer 3

Вот еще одно распространенное использование, которое я видел. Схемы и search_path позволяют двум или более разработчикам работать над одной и той же копией большого БД, не нуждаясь в их собственных копиях, но не мешая друг другу.

Допустим, Джо работает с таблицей комментариев, а Джим работает с таблицей рабочих процессов. Им обоим нужны пользователи, группы и т. Д. Таблицы. Джо создает схему, создает свою собственную рабочую версию таблицы комментариев и может по желанию разобраться с ней:

create schema joe;
create table joe.comments (rest of new tabledef here);
set search_path='joe','public';

Теперь, когда Джо делает alter table в таблице joe.comments, Джим не видит никаких изменений, и его развитие не подвержено повреждению таблицы joe.comments и т. Д. Когда выполняется код Джо, имеющий search_path 'joe','public', он видит таблицы комментариев Джо, в то время как все остальные видят оригинал.

После тщательного тестирования таблица комментариев Джо может быть в основном заменена оригиналом одним махом без прерывания разработки Джима. Умножьте на это время 40 разработчиков, и это позволит всем 40 работать на одном уровне разработки, не взрывая при этом вещи друг друга (или реже, по крайней мере).

Answer 4

Ключевым преимуществом для схем является обеспечение логической группировки таблиц базы данных.Наиболее вероятные варианты использования:

• Для запуска различных логических приложений в одной и той же БД - например, у вас может быть корпоративная система, и вы хотите создать схемы под названием «userprofiles», «projects»,"финансы" и т. д.
• Для создания аналогичных версий одной и той же группы таблиц, например для "разработка", "qa" и "производство"