Здравствуйте, Baiker, Вы писали:

IT>>Сейчас посчитал, порядка 780 таблиц

B>Даже если взять только 300 "самых нужных" всё равно много.

Так у нас же не интернет петшоп. У нас одних поставщиков информации около сотни. Фиды там всякие, чуждые оракловские базы данных. Всё это нужно долго собирать, бережно складывать, аккуратно раскладывать, надёжно хранить.

B>Но вот префиксы чем не угодили?

Симметричный вопрос — чем не угодили схемы? Нафиг эти префиксы нужны, если есть такие удобные и понятные схемы.

B>Когда тебе нужно приджойнить полное имя к персоне, меньше всего хочется думать, в какой схеме лежит Person — хочется внятного интеллисенса и минимум телодвижений.

Т.е. думать о том какая схемы не хочется, а помнить все префиксы для всех таблиц — это самое оно

B>В упомянутом выше PostgreSQL Maestro ты просто умудохаешься прыгавши от узла к узлу (если забыл префиксы и хочешь найти таблицу чисто визуально).

Ну так это проблемы не схем, а PostgreSQL.

B>IT, ещё тонкий момент: я правильно понял, что схемы удобны чисто на этапе разработки для организации таблиц? И для принципиальной работы самой программы эти схемы пофиг.

Пафую. Единственная польза может быть связана с секьюрити. Но нам это не нужно.

ЗЫ. Т.к. мы по базе генерируем полную модель данных для приложений, то схемы позволяют нам группировать сгенерированные классы соответственно. Получается не одна большая помойка на 700 классов, а пару десятков помоечек поменьше, что довольно удобно.

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, Буравчик, Вы писали:

Б>>Схемы нужны в первую очередь для разделения прав. Можно выполнять межсхемные запросы (в отличие от разных БД).

B>Запросы к разным БД есть по кр. мере в MS SQL. И на 51% я уверен, что в Pg они тоже есть.

Нет, в Pg на 100% их нет (только к remote базам через специальный wrapper).

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, AndrewN, Вы писали:

B>>>В PostgreSQL есть такая штука, как scheme (что-то вроде namespace в пределах одной базы).
B>>>Вопрос: насколько полезным вы находите эту фичу и используете ли её вообще? Как часто в проектах вам вот требуется scheme?

AN>>Большая энтерпрайз-приложуха.
AN>>Много компаний-клиентов по России.
AN>>Для каждого Клиента своя "схема" с одинаковым набором таблиц.

B>Логичный вопрос: почему не ОТДЕЛЬНАЯ БАЗА? Ведь это и намного безопаснее, и удобнее в управлении (бэкапы, mirroring, лимиты и т.п.).

Тем что чтобы обсуждать как это должно быть в PostgreSQL, нужно понимать как он работает. Ты похоже не понимаешь.

Здравствуйте, Baiker, Вы писали:

hlt>>Ты директории на диске используешь "вынужденно или потому-что они есть, или это просто вопрос навигации или каких-то административных идей"?
B>Похожая, но в корне неверная аналогия. На диске ВСЕ директории равноценны и имеют неограниченную вложенность. И сама суть работы с диском — сначала навигация по "тематическим папкам", потом работа с файлами внутри.

Схемы в БД — равноценны. Это способ структурирования объектов базы. Те-же самые "тематические папки".

B>Навигация ПРОГРАММИСТА по базе — извини, но это полный бред — распахивать 8 узлов только для того, чтобы узнать, какие у тебя таблицы!
B>А если учесть, что у тебя и схем больше одной, то ты сразу же "попадаешь" на то, что где-то визуально надо запомнить положение "главный узел БД", чтобы от него прыгать вниз "а где же там у меня ещё одна схема?". Маразм. Вот для примера как выглядит "болото навигации" в Maestro:

Что за "главный узел БД"?
Объекты по схемам не рандомно раскидываются. Схемы они "тематические". Например: разделение объектов по пользователям, чтобы не мешать друг-другу на одной среде, либо по командам/проектам чтобы работать независимо, либо разделение "по функциональным слоям" БД, где в каждом слое комплект таблиц, иногда примерно одинаковых.
Ты всегда знаешь в какой схеме тебе нужна таблица, её не нужно искать по разным схемам. Как правило ты и работаешь 99% времени в одной схеме, если ты не etl-щик. Зашёл, выбрал схему один раз утром.

B>Но я не о том... я всё ещё о целесообразности схем при возможности создавать отдельные базы и ставить префиксы.
Как раз создавать отдельные базы в некоторых случаях нецелесообразно.
Отдельные базы лишают тебя возможности просто работать с таблицами из разных баз в одном SQL запросе.
Отдельные базы, на некоторых субд (напр. Oracle) — не простое решение.
Префиксы не решают, например проблем с разделением прав доступа на группы таблиц, а в схемах это врожденное.

Здравствуйте, Baiker, Вы писали:

B>Не о том речь. Я не продвигаю "ребят, бросайте схемы — лепите буквы!" Я хочу узнать, насколько принципиально важно иметь схемы.
Я же написал — делай так, как тебе удобно. Что значит "принципиально важно" в программировании?
Схемы помогут тебе логически разбить сущности по уровням абстракции, не убьют при этом производительность и контроль целостности данных, как разнесение по разным БД, дадут возможность ограничения доступа по этим уровням абстракции, при этом оставаясь в рамках ANSI стандарта. Тебе это принципиально важно? Тогда и схемы тебе принципиально важны. Тебе это нафиг не нужно? Ну, тогда и схемы тебе нафиг не нужны.


B>Вот я как новичок предлагаю префиксы. Но профи могут возразить "префиксы не помогут, потому что наши схемы могут %что-то могут%" — вот что я хочу услышать.
Тебе уже написали, что могут схемы того, чего не могут префиксы.

B>ПОЧЕМУ? Что принципиального даёт схема вместо префикса?
УЖЕ НАПИСАНО ВСЕМИ ПОДРЯД ДО МЕНЯ И МНОЙ ТОЖЕ.
Так видно? Или всё ещё нет?

B>Не ответ вообще.
Вообще-то, ответ. Просто ты не понимаешь, что удобство написания и чтения кода, в том числе его организации — вещь субъективная. Но очень важная.

B>Открой дерево баз в любом менеджере и потыкай. Ты строишь такое недоумение, будто у тебя вообще деревьев нет, а колонка Person.Name доступна в один клик! Может, хватит идиотничать?
Открыл SSMS. Вообще нет разницы, что есть схемы, что нет. Ну, сортировка идёт сначала по схемам, потом по имени таблицы. Но с префиксами разницы нет — там сортировка по имени таблицы автоматически является сортировкой сначала по префиксу. Никаких "деревьев" схемы не создают.
Открыл SSDT или как она там нынче обзывается правильно. Там всё сгруппировано по папкам так, как я определил.

Может хватить идиотничать и грубить только потому, что ты новичок и не разбираешься в MS SQL Server том же?

B>Мне не нужны фаталистические мнения, у меня сугубо инженерный вопрос.
Сугубо инженерный подход — работать с реальным миром и реальными ограничениями. Т.е. с тем, что есть.

Здравствуйте, scf, Вы писали:

scf>Я вижу только две причины использовать схемы вместо баз (create database):
Ты бы указывал ту систему управления РБД, с которой ты работаешь.
Ибо в общем случае такие категорические заявления звучат, уж извини за прямоту, глупо.

scf>- на базе есть запросы, которые используют несколько схем одновременно
scf>Первое это крупный организационный косяк, а второе — почти всегда большой косяк архитектурный.
Э-э-э... С какого перепугу запросы, использующие несколько схем или баз данных являются архитектурным косяком?

Здравствуйте, Baiker, Вы писали:


B>

B>-- есть таблицы scheme1.tab1 и scheme2.tab2
B>SELECT tab1.c1, tab2.c1 ...
B>

B>работать не будет (даже если ВСЕ имена таблиц уникальны).
Мало-мальски опытный DBA (например, студент с полусеместром курса "Базы данных") пишет вот так:

select t1.c1, t2.c1
from scheme1.tab1 t1
inner join scheme2.tab2 t2 on t2.externalId = t1.id

Разницы с предлагаемым вами префиксным подходом — нету:

select t1.c1, t2.c1
from scheme1_tab1 t1
inner join scheme2_tab2 t2 on t2.externalId = t1.id

Ну, кроме того, что таблицу из дефолтной схемы можно использовать и без префикса — а в вашем подходе поменять "дефолтный префикс" невозможно.
B>Соотв. мы обязаны везде и всюду пихать ещё и схему, соотв. загромождая SQL.
Как видим — нет.

B>Если у вас 2 и более схем, не будет работать даже

B>

B>SELECT * FROM tab1
B>

B>!!!
Смотря где вы это пишете. Внутри view, stored procedure, trigger можно обращаться к объектам той же схемы без префикса. Также без префикса можно обращаться к объектам дефолтной схемы.
B>Что уже вообще за рамками, но вполне объяснимо неуклюжестью наличия нескольких схем — ведь у "конекшена" нет 'контекстной схемы'.
В Postgres есть. В MSSQL есть у пользователя.
В вашем предложении обойтись без префиксов будет невозможно вообще никогда:

SELECT * FROM schama1_tab1

B>Вопрос: а почему не разделять таблицы ПРЕФИКСАМИ (как некоторые и говорили в комментах) ? Префикс — он так же будет "мелькать" в SQL, как и схема, но практически все таблицы будут сразу доступны! (в т.ч. и интеллисенсу) Более того — основные таблицы можно вообще делать без префиксов, а с префиксами только те, которые надо логически отделить.
По-моему, ответ уже очевиден.
B>2. Да, обилие таблиц — это проблема. Почему схемы, а не ОТДЕЛЬНАЯ БД?
Потому, что отдельные БД часто хуже работают. Например, невозможно сделать foreign key в другую базу. Эффективность запросов, смешивающих объекты из разных БД, является приемлемой далеко не во всех движках.

Здравствуйте, Baiker, Вы писали:
B>В чём принципиальная польза отдельной базы: она физически отделена от остальных данных и никакой даже самый раздолбайский запрос от джуна не засосёт случайно секретные данные.
Если у джуна есть права на отдельную базу — то прекрасно засосёт.
Если у джуна нет прав на отдельную схему — то не засосёт.

B>Отдельную базу проще бэкапить/ресторить (крайне важно!!)
1. В какой СУБД?
2. Что значит "проще"?

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

Здравствуйте, Baiker, Вы писали:
B>Представьте, что у вас есть отличный БД-менеджер, которому не нужны схемы: вы просто в строке фильтра набрали "ACC_" и вот все ваши таблицы перед глазами (вместо раздражающих прыжков по "деревьям" и распахиванием узлов).
Непонятно, что помешает этому БД-менеджеру показать все таблицы при наборе "в строке фильтра" (кстати, это где вообще?) "acc."?

Здравствуйте, Baiker, Вы писали:
B>1. Практически ВСЁ, что есть в базе, запихано в ДЕРЕВО. Думаю, не надо пояснять, насколько ублюдский этот контрол?
У вас, простите, какая-то каша в голове.
Схема — это часть стандарта SQL. Она существует сама по себе, и её ограничения и возможности спроектированы для решения административных задач.
В частности, для упрощения раздачи прав и предотвращения конфликтов имён, когда одну и ту же БД совместно используют несколько групп пользователей.

Дерево — это часть UI одного конкретного софта по менеджменту СУБД. Это далеко не единственный инструмент, существующий на рынке.
Я вообще большинство вещей делаю через собственно SQL-команды. А "дерево" — это инструмент discovery, который мне помогает в отстутсвие (или кривость) автокомплита в SQL-редакторе.
Я видел инструменты, в которых никакого дерева слева нету, а вместо него строчка фильтра, под которым плоский список таблиц/view, которые можно раскрыть и посмотреть их колонки.
В обоих сценариях схемы прекрасно работают, ничему не мешая. Если вам мешают — ну, напишите свой собственный менеджер для СУБД, в котором все таблицы будут в одном плоском узле, а имя схемы будет просто префиксом в стиле "acc.users".

B>Как визуализатор — дерево прекрасно! Узлы, подузлы, списки... Но как навигатор дерево просто ужасно. Бесконечные кликания по мелким квадратикам, распахивание излишних узлов, загромождение по вертикали... это мрак!
Пока что совершенно непонятно, в рамках какого сценария у вас возникают "бесконечные кликания по мелким квадратикам".

B>2. Схемы, как и положено тупоголовым погромиздам, аккуратно вкорячены в дерево. Так что если твой визуальный контекст — схема А, тебе придётся щуриться и лазить по дереву "где же узел схемы Б", чтобы опять бесконечно распахивать узлы в поисках нужной колонки, но из другой схемы.
Звучит так, что в вашем редакторе SQL нет автокомплита, но при этом вам почему-то постоянно нужно писать запросы с пересечением границы схем, которые вам ещё и незнакомы (так что вы не помните ни названий конкретных таблиц и колонок, ни схемы именования).

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

Здравствуйте, _ABC_, Вы писали:

_AB>Ты бы указывал ту систему управления РБД, с которой ты работаешь.

В названии топика написано PostgreSQL, конечно же я про неё.

_AB>Э-э-э... С какого перепугу запросы, использующие несколько схем или баз данных являются архитектурным косяком?

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

Конечно, есть исключения, тот же ETL, но современные приложения стараются не использовать ETL для переноса данных между разными системами, именно по этим соображениям.

B>Представьте, что у вас есть отличный БД-менеджер, которому не нужны схемы: вы просто в строке фильтра набрали "ACC_" и вот все ваши таблицы перед глазами (вместо раздражающих прыжков по "деревьям" и распахиванием узлов).

Конечно, на вкус и цвет товарища нет — но много ли найдется таких людей, которым набрать в строке фильтра "ACC_" будет проще, чем ткнуть в узел дерева "ACC"?
Учитывая, что префикс — еще запомнить надо, какой набирать для интересующей тебя группы таблиц. А список схем ты видишь перед собой — и даже если точно не знаешь, какая нужная, можешь это интуитивно предположить по названию.

Здравствуйте, scf, Вы писали:

scf>Когда несколько приложений используют одни и те же таблицы в базе, это существенно усложняет развитие этой базы.
Э-э-э... А при чем тут запрос, использующий несколько схем или БД?
Или просто воды решил налить, чтобы отвлечь от вопроса?

scf>Когда одно приложение использует один запрос по разным базам, это на порядок хуже,
Обоснуй, пожалуйста. Почему хуже?

scf>с таким подходом получается уже несколько баз, монолитно спаянных между собой приложениями, которые их используют одновременно.
Э-э-э... С какого перепугу обязательно будет несколько приложений?

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

Запрос. Один. Использует несколько схем. Или БД.
В чём архитектурный косяк этого запроса, использующего несколько схем? Или БД?
Не наличия нескольких приложений, работающих с теми же данными. Запроса. Одного.

Здравствуйте, _ABC_, Вы писали:

_AB>В чём архитектурный косяк этого запроса, использующего несколько схем? Или БД?
_AB>Не наличия нескольких приложений, работающих с теми же данными. Запроса. Одного.

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

Здравствуйте, scf, Вы писали:

scf>Здравствуйте, _ABC_, Вы писали:

_AB>>В чём архитектурный косяк этого запроса, использующего несколько схем? Или БД?
_AB>>Не наличия нескольких приложений, работающих с теми же данными. Запроса. Одного.

scf>Несколько разных баз предполагают несколько разных приложений, использующих эти базы.
Вовсе не обязательно. У меня одно приложение/платформа и десятки БД на одном сервере для него/неё, например.

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

1. Архивные данные вынесены в отдельную БД. Это позволит упростить/ускорить сценарии восстановления, упростить админинистрирование ограничения доступа к архивным данным, обслуживание БД, распределение ресурсов. И в целом сценарии с восстановлением ASAP "горячего" функционала с последующим последовательным восстановлением менее критичного функционала приложения в условиях большого объёма данных. Да, MS SQL Server тот же позволяет многое из этого решить внутри одной БД (но многое из этого со схемами, которые ты не любишь и только с Enterprise Edition), но отделение в другую БД делает это ещё проще и внутри более дешёвых редакций. А "ещё проще" очень важно, т.к. хороших ДБА в мире очень мало, к сожалению.
2. Данные разных клиентов вынесены в разные БД в рамках облачного multi-tenant приложения. Это позволит упростить физическое разделение данных клиентов, упростит сценарии восстановления основного функционала, а также откат данных одного клиента в изоляции от всех других при необходимости, ну и также обслуживание и ограничение доступа тоже. Если мне будет надо, я их ещё и по разным серверам раскидаю без проблем и с минимальными изменениями в самом приложении, но пока обходимся раскидками на уровне hosted zones и разных экземпляров/узлов всего приложения.

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

2. Попробуй задуматься. Вопрос был очень простой. Один запрос. Один. Запрос. Один. К разным схемам. Один запрос. Одно приложение. Почему один запрос к нескольким схемам — это огромный архитектурный косяк?

Здравствуйте, scf, Вы писали:

scf>Здравствуйте, _ABC_, Вы писали:
_AB>>В чём архитектурный косяк этого запроса, использующего несколько схем? Или БД?
_AB>>Не наличия нескольких приложений, работающих с теми же данными. Запроса. Одного.

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

Ничего странного в этом нет.
Так называемая "мультитенантная архитектура"

Приложение одно. Структура таблиц в базе — одинаковая.

А работают с ним много разных организаций клиентов — и каждый со своими собственными данными в отдельной схеме/базе (данные разные, а набор таблиц одинаковый).

Кроме наличия отдельной схемы под каждого клиента — может существовать еще и отдельная схема с ОБЩИМИ данными приложения (например со всеми "строками", использующимися в приложении). Они одинаковые для всех клиентов (т.к. приложение одно) и иметь копию этих данных в базе каждого отдельного клиента — нецелесообразно.

Здравствуйте, Sinclair, Вы писали:

S>Мало-мальски опытный DBA (например, студент с полусеместром курса "Базы данных") пишет вот так:

S>select t1.c1, t2.c1
S>from scheme1.tab1 t1
S>inner join scheme2.tab2 t2 on t2.externalId = t1.id

Дай Бог здоровья его преподавателям // за правильный подход к использованию алиасов

Здравствуйте, Baiker, Вы писали:

B>Ребят, нужна небольшая статистика/мнения по поводу одной фичи. Поделитесь пожалуйста опытом!
B>В PostgreSQL есть такая штука, как scheme (что-то вроде namespace в пределах одной базы).
B>Вопрос: насколько полезным вы находите эту фичу и используете ли её вообще? Как часто в проектах вам вот требуется scheme?

Работаем с микросервисами в кубере. Каждому микросу выделяется отдельная схема.

По теории у каждого микроса должна быть своя БД, но на практике у нас в проде на одном кубере в нашей экосистеме 600-700 сервисов, у 90% которых собственная БД.
При таких количествах процесс администрирования сервера БД превращается в ад.
Поэтому архитекторы приняли решение заводить для отдельных микросервисов схемы в общей БД.

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

Как-то так.

Здравствуйте, Baiker, Вы писали:

F>>И имена таблиц в между командами вообще запросто могут и совпадать

B>Тем более возникает вопрос об отделении в другую БД. Почему именно schemes?

B>И отдельно вопрос по удобству: а префиксы не спасут ситуацию? (это если прям необходимо всех засунуть в одну БД) Фактически, схемы и есть своеобразный префикс, только доставляющий гемор, когда тебе нужно приджойнить "чужую" таблицу, но в твоём нэймспэйсе её нет.

Это не гемор. Это точка, в которой нужно задуматься, для чего схемы в вашей бд и нужно ли джойнить таблицу из другой схемы.
Если сценарий использования — схема на микросервис или на команду, с перспективой разнесения в разные БД — то дджойня таблицу вы скорее всего делаете что-то не так.
Если же у вас джойны таблиц из других схем это норма и все так делают — обсудите с коллегами, зачем вообще в вашем проекте были созданы схемы. У вас возможно действительно проще обойтись префиксами.

Здравствуйте, Baiker, Вы писали:

_FR>>Так же по схемам можно разграничивать права. Если ни то ни другое вам не нужно, то, быть может, и схемы не нужны.

B>Согласен. Тем более, что заплесневелая "система прав" идёт из лохматых 70-ых, когда о трёхзвенках и не слышали! (а потому лепили "пермишены" прямо в БД)
B>Апп.сервер даст стократ более гибкий И УДОБНЫЙ метод разграничений, чем все эти пляски с ролями, схемами, правами и т.п.

Пермишны на уровне БД полезны даже при наличии трехзвенки. Это повышает трудозатраты на взлом системы. Например компрометация логина/пароля имеющих доступ к схеме заказов, не приведет к компрометации персональных данных. Хотя это утрированный пример, так как хранить персональные данные лучше отдельно и с шифрованием, но суть такая.