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

F>
F>20-30. Вот у меня сейчас проект (на Оракле, правда), в той схеме, где работает наша команда — более 200 таблиц

Можно узнать, в какой предметной области нужно столько отдельных сущностей?? Или это архитектурное решение, а сущностей гораздо меньше?

F>Но количество это еще не самое главное. Более важно разделение. Рядом работает еще несколько команд, у них тоже там по 100 и более своих таблиц, но они никак не перемешиваются с нашими таблицами

Возникает логичный вопрос: а чего бы тогда этим командам не ваять свои таблицы в отдельной БД?? Ведь если вы логически отделили таблицы нэймспэйсами, так может они вообще отдельный домен(бизнес область)? По кр. мере MS SQL спокойно делает джойны из разных БД.

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

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

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

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

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

Я бы предпочёл префиксы. Отдельная схема — это сразу целая "область таблиц", работа с которой напрямую невозможна и тебе придётся в каждом доступе к БД дополнительно указывать схему.

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

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

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

IT>Когда таблиц всего пару сотен, как тут у одного коллеги с рукалицом, то ещё можно обойтись. Если больше, то схемы помогают.

А можно узнать, в какой предметной области нужно так много таблиц? Спрашиваю чисто из любопытства, конечно же если их сделали 1000 штук, значит за этим была логика.
Ну и попутно: а просто префиксы типа "HR_Person" не помогут? Обязательно надо всё рубить так, чтоб прямо отдельная схема?

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

_AB>Вопрос не в путанице, вопрос в удобстве логического разделения и экономии времени. На том же интеллисенсе, например

Вот хороший пример порассуждать! А почему не префиксы? Схемы — это практически то же самое, только с жёстким отделением таблиц. А так набрал "Buh_" — вот тебе таблицы из бухгалтерии Почему именно схемы? Что они дают помимо интеллисенса?
Представьте, что у вас есть отличный БД-менеджер, которому не нужны схемы: вы просто в строке фильтра набрали "ACC_" и вот все ваши таблицы перед глазами (вместо раздражающих прыжков по "деревьям" и распахиванием узлов).

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

Q>Наличие нэймспэйсов — это только полдела, нужно что бы инструмент работы с бд, их как то адекватно отображал(что-то типа папок с объектами бд) что бы комфортно можно было работать, а так используем прифигсы.

У меня возникает ровно такая же идея: зачем прямо "физически" рубить таблицы по схемам, если простой префикс прекрасно справляется? Отфильтровал таблицы по префиксу — всё, вот твоё рабочее поле. Набрал чужой префикс — и интеллисенс так же легко выдаст нужные таблицы. Зато запросы не будут кишеть этими самыми схемами.

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

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

Q>>Наличие нэймспэйсов — это только полдела, нужно что бы инструмент работы с бд, их как то адекватно отображал(что-то типа папок с объектами бд) что бы комфортно можно было работать, а так используем прифигсы.

hlt>Чем не устраивает DBeaver или любой другой (они все объекты по схемам отображают)?

В этом и проблема...

1. Практически ВСЁ, что есть в базе, запихано в ДЕРЕВО. Думаю, не надо пояснять, насколько ублюдский этот контрол? Как визуализатор — дерево прекрасно! Узлы, подузлы, списки... Но как навигатор дерево просто ужасно. Бесконечные кликания по мелким квадратикам, распахивание излишних узлов, загромождение по вертикали... это мрак!
2. Схемы, как и положено тупоголовым погромиздам, аккуратно вкорячены в дерево. Так что если твой визуальный контекст — схема А, тебе придётся щуриться и лазить по дереву "где же узел схемы Б", чтобы опять бесконечно распахивать узлы в поисках нужной колонки, но из другой схемы.

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

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

VC>Это не просто неймспейсы, потому что на схемы можно выставлять права.

Сразу нет. Замшелые идеи юзеров/ролей/схем показали свою практическую непригодность. Теоретически они прекрасны, но спросите любого программера хочет ли он потратить пол-года ещё и на DBA, чтобы только правильно оперировать сущностями в БД — он сразу откажется. Любой апп.сервер (в раздаче прав) на порядок лучше и гибче субд-шных схем.


VC>Другой юз кейс это когда задается search_path на конкретную схему. Например multi-tenancy, и подобные другие вещи, когда для нескольких (или для многих) пользователей данные хранятся в одной и той же структуре но физичеси разные

Не понял идеи (даже не слышал никогда). Это как?? В смысле две таблицы из разных схем объединяются в одну?

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

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

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

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

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

Чем дешевле? Что одна база распухает донельзя? Один сервер, много баз — чем плохо?

Ребят, всем спасибо за ответы!

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

1. Многие говорят об удобном логическом отделении имён. Увы, но это не просто "логически", но и физически отделено! Вот это:

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

работать не будет (даже если ВСЕ имена таблиц уникальны). Соотв. мы обязаны везде и всюду пихать ещё и схему, соотв. загромождая SQL. Если у вас 2 и более схем, не будет работать даже

SELECT * FROM tab1

!!!
Что уже вообще за рамками, но вполне объяснимо неуклюжестью наличия нескольких схем — ведь у "конекшена" нет 'контекстной схемы'.

Вопрос: а почему не разделять таблицы ПРЕФИКСАМИ (как некоторые и говорили в комментах) ? Префикс — он так же будет "мелькать" в SQL, как и схема, но практически все таблицы будут сразу доступны! (в т.ч. и интеллисенсу) Более того — основные таблицы можно вообще делать без префиксов, а с префиксами только те, которые надо логически отделить.

2. Да, обилие таблиц — это проблема. Почему схемы, а не ОТДЕЛЬНАЯ БД? Например, MS SQL может запросто "лефт джойнить" таблицы даже из разные баз!
В пользу отдельной БД ещё и удобство менеджмента/секурности. Да и в целом, в ИТ хорошо прижился принцип "разделяй и властвуй". Меньше зависимостей — гибче система.

Что скажете?

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

B>Вот хороший пример порассуждать! А почему не префиксы?
Можешь использовать префиксы, кто тебе запретит? Используй то, что тебе удобно.
В динамически создаваемых БД у нас префиксы по историческим причинам. Сегодня, если бы писал с нуля, я бы, скорее всего, использовал и там схемы.

B>Почему именно схемы? Что они дают помимо интеллисенса?
Мне они нравятся больше, чем префиксы.

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

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

B>Сразу нет. Замшелые идеи юзеров/ролей/схем показали свою практическую непригодность. Теоретически они прекрасны, но спросите любого программера хочет ли он потратить пол-года ещё и на DBA, чтобы только правильно оперировать сущностями в БД — он сразу откажется. Любой апп.сервер (в раздаче прав) на порядок лучше и гибче субд-шных схем.

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

Еще примеров:
— юзаешь библиотеку, ей нужна БД — помещаешь ее в свою схему
— пользователю нужно иметь свои (временные) таблицы в БД — выделяешь для него свою схему

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

B>1. Практически ВСЁ, что есть в базе, запихано в ДЕРЕВО. Думаю, не надо пояснять, насколько ублюдский этот контрол? Как визуализатор — дерево прекрасно! Узлы, подузлы, списки... Но как навигатор дерево просто ужасно. Бесконечные кликания по мелким квадратикам, распахивание излишних узлов, загромождение по вертикали... это мрак!
B>2. Схемы, как и положено тупоголовым погромиздам, аккуратно вкорячены в дерево. Так что если твой визуальный контекст — схема А, тебе придётся щуриться и лазить по дереву "где же узел схемы Б", чтобы опять бесконечно распахивать узлы в поисках нужной колонки, но из другой схемы.

Не хочешь кликать — работай из командной строки. Никто не заставляет DBeaver использовать, psql же есть!

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

Ты директории на диске используешь "вынужденно или потому-что они есть, или это просто вопрос навигации или каких-то административных идей"?

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

B>Ребят, всем спасибо за ответы!
Да пожалуйста.

B>1. Многие говорят об удобном логическом отделении имён. Увы, но это не просто "логически", но и физически отделено! Вот это:

B>

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

B>работать не будет (даже если ВСЕ имена таблиц уникальны). Соотв. мы обязаны везде и всюду пихать ещё и схему, соотв. загромождая SQL.
Э-э-э... У тебя реально имена таблиц из четырёх символов максимум? И ты реально в селекте прописываешь полное имя атрибута?
Просто на практике, что с префиксами, что со схемами, я всё равно задам альяс таблице, а не буду прописывать полное имя таблицы при указании столбца. Аргумент, ИМХО, полностью оторван от жизни.

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

B>SELECT * FROM tab1
B>

1. Давно не брал я в руки шашки, но в MS SQL разве не будет использоваться дефолтная схема пользователя в этом случае?
2. Зачем писать небрежно? Не пропускай такое через код ревью, если у вас в наличии схемы и, особенно, одинаковые названия таблиц в разных схемах.

B>Что уже вообще за рамками, но вполне объяснимо неуклюжестью наличия нескольких схем — ведь у "конекшена" нет 'контекстной схемы'.
В MS SQL Server есть default schema у пользователя.
https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-user-transact-sql?view=sql-server-ver16

B>2. Да, обилие таблиц — это проблема. Почему схемы, а не ОТДЕЛЬНАЯ БД? Например, MS SQL может запросто "лефт джойнить" таблицы даже из разные баз!
Насколько я помню, там могут быть сюрпризы с оптимизацией.
Плюс ты не сможешь создать FK на таблицу в другой БД, например. Придётся обеспечивать целостность через тригеры, что хуже со всех точек зрения, ИМХО.

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

Не, использование разных БД — вполне себе паттерн, так сказать. И мы его используем в своём продукте очень широко. Но для физического разделения данных наших клиентов, а не для логического разделения таблиц.

B>Что скажете?
1. По указанию полного имени таблицы вместо альяса — такого на практике я не встречал. Хреновые альясы — сплошь и рядом, но чтобы не ленились указывать имя таблицы целиком — не-а.
2. "Контекстная схема" для пользователя и его соединения в MS SQL Server есть, но, ИМХО, в целом это плохая практика и неряшливость — не указывать имя схемы для таблицы, если есть больше, чем одна схема в БД.
3. Префиксы с моей эстетической точки зрения выглядят более неряшливо и несколько хуже читаются мною лично. Это чисто субъективизм, но что есть, то есть.
4. Отдельная БД вместо схемы — это дополнительный оверхед в администрировании (который обязательно всплывёт при DR) и возможные неожиданные проблемы с производительностью на ровном месте. Плюс потеря возможности обеспечения целостности на уровне связей между таблицами, разведёнными в разные БД. Да и в случае чего сменить схему для таблицы куда проще, чем перенести таблицу из одной БД в другую. Это если ты решил, что ошибся в логическом разделении таблиц.

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

B>А можно узнать, в какой предметной области нужно так много таблиц? Спрашиваю чисто из любопытства, конечно же если их сделали 1000 штук, значит за этим была логика.

Обычный кговавый интегпгайз. Собираем данные, обрабатываем, генерируем, репортируем. Сейчас посчитал, порядка 780 таблиц. Но почти половина из них находится в отдельной схеме и нужна для архивации данных. Схема и дубль структуры таблиц — идиотское специфическое требование системы архивирования. Я бы лучше это вынес в отдельную БД.

B>Ну и попутно: а просто префиксы типа "HR_Person" не помогут? Обязательно надо всё рубить так, чтоб прямо отдельная схема?

Какая разница HR_Person или HR.Person? Можно вообще [HR.Person] и не схема и выглядит как схема.

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

B>Спрашиваю здесь, потому что это именно прикладной вопрос для программистов, насколько "разветвлённые" у них базы и есть ли смысл заморачиваться с нэймспэйсами.

Я вижу только две причины использовать схемы вместо баз (create database):
— создание новых баз затруднено организационно админами, а вот схемы создавать дают
— на базе есть запросы, которые используют несколько схем одновременно

Первое это крупный организационный косяк, а второе — почти всегда большой косяк архитектурный.

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

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

B>>Вот хороший пример порассуждать! А почему не префиксы?
_AB>Можешь использовать префиксы, кто тебе запретит?

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


_AB>В динамически создаваемых БД у нас префиксы по историческим причинам. Сегодня, если бы писал с нуля, я бы, скорее всего, использовал и там схемы.

ПОЧЕМУ? Что принципиального даёт схема вместо префикса?

B>>Почему именно схемы? Что они дают помимо интеллисенса?
_AB>Мне они нравятся больше, чем префиксы.

Не ответ вообще.

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

Открой дерево баз в любом менеджере и потыкай. Ты строишь такое недоумение, будто у тебя вообще деревьев нет, а колонка Person.Name доступна в один клик! Может, хватит идиотничать?

_AB>2. Я могу представлять всё, что угодно, но работать я буду всё равно с тем, что есть.

Мне не нужны фаталистические мнения, у меня сугубо инженерный вопрос.

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

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

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

Б>Еще примеров:
Б>- юзаешь библиотеку, ей нужна БД — помещаешь ее в свою схему

Нет, такой узкий случай не принципиален. Я знаю одну дебильную программу (VS), которой для того, чтобы начертить диаграмму классов, нужно устанавливать весь MS SQL!! Но это скорее маразматическое исключение. Как правило, БД проектируется одна на весь продукт и "подключенная либа" не может/не должна на это влиять.

Б>- пользователю нужно иметь свои (временные) таблицы в БД — выделяешь для него свою схему

Опять же, какой-то специфичный кейс, к которому я могу предложить 5 решений БЕЗ схем.

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

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

hlt>Ты директории на диске используешь "вынужденно или потому-что они есть, или это просто вопрос навигации или каких-то административных идей"?

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

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



СЕМЬ(!!!) узлов надо распахнуть для того, чтобы увидеть 'orders'. А теперь на этом мелком ублюдстве (которое даже в сеттингах не увеличивается) найди мне pub2. Оно ВООБЩЕ НИКАК не отличается от практически всех элементов дерева. Тут 2 балла по "юзабилити" и пинком под зад! А вот как это делают квалифицированные инженеры:




Согласись, это просто пропасть между "прыжкам по деревьям" и этим.

Но я не о том... я всё ещё о целесообразности схем при возможности создавать отдельные базы и ставить префиксы.

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

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

Даже если взять только 300 "самых нужных" всё равно много. Но вот префиксы чем не угодили? Неужели программисту проще полностью "окунаться в схему" (которая похожа вообще на отдельную базу), чем просто поставить префикс? Отсортировал — всё на своих местах. Отфильтровал — видишь нужные таблицы.


B>>Ну и попутно: а просто префиксы типа "HR_Person" не помогут? Обязательно надо всё рубить так, чтоб прямо отдельная схема?

IT>Какая разница HR_Person или HR.Person? Можно вообще [HR.Person] и не схема и выглядит как схема.

Разница огромна, я там выше написал: если у тебя ДВЕ схемы, ты даже SELECT FROM table не сделаешь, если table во второстепенном нэймспэйсе. Кроме того, с префиксами нет потребности "прыгать по деревьям" (я про навигацию в базе). Все таблицы одним скопом. Когда тебе нужно приджойнить полное имя к персоне, меньше всего хочется думать, в какой схеме лежит Person — хочется внятного интеллисенса и минимум телодвижений.
В упомянутом выше PostgreSQL Maestro ты просто умудохаешься прыгавши от узла к узлу (если забыл префиксы и хочешь найти таблицу чисто визуально).

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

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

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

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

В чём принципиальная польза отдельной базы: она физически отделена от остальных данных и никакой даже самый раздолбайский запрос от джуна не засосёт случайно секретные данные. Отдельную базу проще бэкапить/ресторить (крайне важно!!) Т.е. если накосячили в бухгалтерии, мы ТОЛЬКО их базу и ресторим, а не хреначим глобальный ресет!
А в процессе разработки (когда с базой идут всякие эксперименты и рефакторинги) десятикратно важно не пересекаться с чужими таблицами.