Практичне використання схем у Postgresql – коли вони потрібні
Почитала https://www.postgrespro.ru/doc/ddl-schemas.html але є незрозумілі: Щоб одну базу даних могли використовувати кілька користувачів, незалежно один від одного. А що буде, якщо кілька користувачів будуть на одну public-схему коннектитися? Щоб організувати об'єкти бази даних у логічні групи, щоб зробити їх більш прозорими в управлінні.
p align="justify"> Різні додатки можуть бути розміщені в окремих схемах, щоб не було конфліктів у використанні імен або інших об'єктів. тобто при роботі в постгрі краще замість окремих баз робити різні схеми в одній і використовувати одну базу з різними схемами для невеликих проектів? Чи це все спрямоване на величезні інфраструктури з репліками-шардами та іншим, а для скормних хом'ячків з цим можна не морочитися? або є сенс виділяти в окремі схеми таблиці з логами, до яких застосовується партіціонування, об'ємні таблиці зі статистиками аналітиками
Якщо сформулювати коротко, то розбиття на бази даних – це для адміністраторів БД, а розбиття на схеми – це для адміністраторів даних та розробників додатків, щоб їм було легше.
А що буде, якщо кілька користувачів будуть на одну public-схему коннектитися? Окрім того, що схема – це простір імен, у більшості СУБД це ще й простір безпеки. Навіть у рамках одного багатокомпонентного додатка є сенс ставити межі безпеки для обмеження можливих втрат та руйнувань у разі компрометації одного з компонентів.
тобто при роботі в постгрі краще замість окремих баз робити різні схеми в одній Як ви вже зрозуміли - для незалежних додатків, які можуть і повинні існуватиокремо один від одного – краще робити різні бази. Тоді адміністратори зможуть спокійно переносити бази з сервера на сервер незалежно їх бекапит і т.д. Для компонентів однієї програми потрібно використовувати схеми.
Ось вам ще добрий приклад. У вас є програма для ведення бухгалтерії та складського обліку на фірмі. При цьому склалося так, що вам потрібно зберігати на одному сервері дані декількох фірм (наприклад, ви надаєте готовий сервіс під ключ кільком клієнтам). У цій ситуації більш ніж логічно зберігати дані різних клієнтів у різних БД, а дані бухгалтерського та складського обліку - у різних схемах у межах однієї БД конкретного клієнта.