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

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

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

Преимущества использования и потенциального использования # 1

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

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

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

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

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

Я также смущен о реализации/характере схем.
Предположим, что у нас есть 1 DB, который имеет 3 схемы. 1 на пользователя как такового:
user1 = 'admin' - tableA, tableU, tableJ, tableK,
user2 = 'joe' ------ tableU, tableJ,
user3 = 'kate ----- tableU, tableK.

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

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

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

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

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

EDIT v.3

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

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

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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