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

Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того? Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!
PS
Спрашиваю здесь, потому что это именно прикладной вопрос для программистов, насколько "разветвлённые" у них базы и есть ли смысл заморачиваться с нэймспэйсами.

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

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

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

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

B>Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того? Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!


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

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

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

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

B>Вопрос: насколько полезным вы находите эту фичу и используете ли её вообще? Как часто в проектах вам вот требуется scheme?

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

B>Вопрос: насколько полезным вы находите эту фичу и используете ли её вообще? Как часто в проектах вам вот требуется scheme?

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

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

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

Используем. В MS SQL. В основном для логического разделения таблиц по подсистемам. Staging таблицы отдельно. Когда таблиц всего пару сотен, как тут у одного коллеги с рукалицом, то ещё можно обойтись. Если больше, то схемы помогают.

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

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

B>Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того? Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!
B>PS
B>Спрашиваю здесь, потому что это именно прикладной вопрос для программистов, насколько "разветвлённые" у них базы и есть ли смысл заморачиваться с нэймспэйсами.

Использую крайне редко, на моей памяти только один раз использовал. Но всё же считаю нужной фичей, вполне вижу варианты, когда оно может пригодиться.

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

B>Вопрос: насколько полезным вы находите эту фичу и используете ли её вообще? Как часто в проектах вам вот требуется scheme?
Полезная, использую в MS SQL Server в своём проекте, который создавал с нуля.

B>Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того?
У меня в проекте всего 126 таблиц в основной базе. Но примерно 890 объектов (всего порядка мегабайта кода) — таблиц, хранимок, функций, которые написаны вручную и требуют периодического (пусть сегодня и редкого) просмотра, отладки, оптимизации. Все они логически распределены по своим схемам.

B>Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!
Вопрос не в путанице, вопрос в удобстве логического разделения и экономии времени. На том же интеллисенсе, например. Я не всегда помню все имена таблиц и, особенно, хранимок, но схемы я помню. Набрал схему, посмотрел по интеллисенсу, что она вывела, дальше работаешь. Новые люди, которые приходили к нам, тоже говорили, что логическая разбивка по схемам помогает им понять структуру БД намного быстрее. Опять существенная экономия времени. И при этом у меня нет двух объектов с одним именем, но в разных схемах.

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

B>Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того? Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!

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

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

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

B>Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того? Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!
B>PS
B>Спрашиваю здесь, потому что это именно прикладной вопрос для программистов, насколько "разветвлённые" у них базы и есть ли смысл заморачиваться с нэймспэйсами.

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

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

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

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

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

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

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

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

Тем, что на прод всем не поставишь, а без лазанья на проде в бд, у нас как-то не получается, бд юзаем через SSMS а она везде стоит.

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

hlt>>Чем не устраивает DBeaver или любой другой (они все объекты по схемам отображают)?
Q>Тем, что на прод всем не поставишь, а без лазанья на проде в бд, у нас как-то не получается, бд юзаем через SSMS а она везде стоит.

Зачем "ставить на прод" дб-тул? Почему нельзя поставить "всем"? Зачем вообще на прод лазать, да ещё и "всем"?

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

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

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

Q>Тем, что на прод всем не поставишь, а без лазанья на проде в бд, у нас как-то не получается, бд юзаем через SSMS а она везде стоит.

Оффтоп, но посоветую cloudbeaver. Ставится на сервер. Предоставляет неплохой веб-интерфейс.

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

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

hlt>>>Чем не устраивает DBeaver или любой другой (они все объекты по схемам отображают)?
Q>>Тем, что на прод всем не поставишь, а без лазанья на проде в бд, у нас как-то не получается, бд юзаем через SSMS а она везде стоит.

hlt>Зачем "ставить на прод" дб-тул? Почему нельзя поставить "всем"? Зачем вообще на прод лазать, да ещё и "всем"?

Под "всем" имеются ввиду клиенты, их разнообразные серверы это может быть и win 7 стоящий компьютере у девочки на ресепшене, так и последний win server. Да есть такие клиенты, которые экономят на it-инфрастрктуре.
Вообще у нас двухзенка со всеми ее недостатками.

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

hlt>>Зачем "ставить на прод" дб-тул? Почему нельзя поставить "всем"? Зачем вообще на прод лазать, да ещё и "всем"?

Q>Под "всем" имеются ввиду клиенты, их разнообразные серверы это может быть и win 7 стоящий компьютере у девочки на ресепшене,


Девочка на ресепшене использует базу через SSMS?

Еще и с правами owner'а небось?

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

Q>Под "всем" имеются ввиду клиенты, их разнообразные серверы это может быть и win 7 стоящий компьютере у девочки на ресепшене, так и последний win server. Да есть такие клиенты, которые экономят на it-инфрастрктуре.
Q>Вообще у нас двухзенка со всеми ее недостатками.

А зачем клиентам дб-тул?
Клиенты обычно только патчи накатывают, им кроме liquibase и не нужно ничего.

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

B>В PostgreSQL есть такая штука, как scheme (что-то вроде namespace в пределах одной базы).

По идее это используется везде где принят DDD, т.e. Enterprise, Banking…

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

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

B>Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того? Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!
B>PS
B>Спрашиваю здесь, потому что это именно прикладной вопрос для программистов, насколько "разветвлённые" у них базы и есть ли смысл заморачиваться с нэймспэйсами.

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

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

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

B>Спрашиваю отчасти потому, что сидя в MS SQL никогда не использовал их scheme. Ну создам 20-30 таблиц — что с того? Путаницы никогда не возникало, потому что не было таких "хитрых" задач иметь, к примеру, две таблицы Person!
B>PS
B>Спрашиваю здесь, потому что это именно прикладной вопрос для программистов, насколько "разветвлённые" у них базы и есть ли смысл заморачиваться с нэймспэйсами.

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

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

Здравствуйте, 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 таблиц в каждом "бизнес-домене", а пересекаются они всего лишь по десятку справочников, можно сделать отдельный микросервис для общих вещей, а все схемы вынести в отдельные базы.

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

Здравствуйте, 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>Апп.сервер даст стократ более гибкий И УДОБНЫЙ метод разграничений, чем все эти пляски с ролями, схемами, правами и т.п.

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

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

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

BVA>Пермишны на уровне БД полезны даже при наличии трехзвенки. Это повышает трудозатраты на взлом системы

Тут надо откатиться назад и вспомнить, что речь про программистов и БД — это вообще не их компетенция "взлом базы". Не говоря о том, что если хацкер поимел доступ вообще к базе, пермишены по схемам уже мало чем помогут.
Ну и третий момент, знания по DBA. Далеко не все программисты могут "залезть и поменять права" на какую-то таблицу или схему. А косяки от "интуитивного метода тыка" нубами ещё хлеще. Другими словами, вместо отдельных скилов по СУБД (да, и по какой? Ораклу? MS SQL? Или предлагаете учиться сразу на все СУБД?) проще использовать базу именно как "хранилище", а бизнес-логику (те самые права) делать на всем понятном Апп.сервере (централизованно). Меньше всего я хочу прыгать в отладчике кода "почему я не могу получить список городов" только из-за того, что где-то в БД небрежный товарищ забыл добавить прав.

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

B>Вопрос: насколько полезным вы находите эту фичу и используете ли её вообще? Как часто в проектах вам вот требуется scheme?

Я ещё раз прочитал весь топик. Ребят, извините все, кого задел сованием "префиксов", немного сложно перестроить мышление, если никогда схемами не пользовался Итак, понятно — схемы нужны и важны! Даже не с позиций прав, а хотя бы "отделить своё от не своего".
Т.к. оригинальный вопрос был в контексте управления БД через ГУЙ, возникает следущий вопрос:

КАК ИМЕННО вы работаете со схемами? Прям вот ежедневная рутина. Вы выбираете одну схему и в ней торчите весь день? Вы работаете сразу с 2-3 схемами? Удобно ли иметь тупо плоский список таблиц и фильтровать его по схемам? Это не вопрос, как вы ПИШЕТЕ SQL запросы — я про общую работу в каком-нть менеджере. Чего нехватает для удобства работы со схемами?
Черкните пару строк, если не лень. Типа "в Прога1 сделано так, а мне удобно, чтобы вот так".

Вот там, где я говорил про "дерево навигации", это было про Maestro — тоже графический тул, но в гробу я видал прыгать по его деревьям... Если с двумя схемами я ещё разберусь, то распахивать дерево для десяти схем — это уже полный маразм и потеря производительности.

Здравствуйте, Baiker, Вы писали:
B>Тут надо откатиться назад и вспомнить, что речь про программистов и БД — это вообще не их компетенция "взлом базы". Не говоря о том, что если хацкер поимел доступ вообще к базе, пермишены по схемам уже мало чем помогут.
Это не совсем так.
Грубо говоря, у вас с одной базой может работать несколько сервисов.
И если в одном из них обнаружилась уязвимость типа SQL injection, то при использовании "root access" на всю базу (а то и кластер) вы дадите злоумышленнику возможность утащить вообще всё.
А раздача прав на уровне хотя бы сервис:схема всё же даст изоляцию "отсеков" вашего авианосца друг от друга.
Скажем, сервис, который трекает отзывы клиентов о вашем банке может быть делегирован нубасам, которые вообще ни в зуб ногой в правильных техниках — и даже если его сломать, то максимум что получит злоумышленник — сломает рейтинги. А доступа к данным банковского ядра (обработке транзакций) он так и не получит.

То есть безопасность — это небинарная величина, типа "нет физического доступа базе" либо "есть физический доступ к базе".
Гораздо чаще реальная уязвимость расположена где-то посередине этого спектра, и изоляция её последствий всё ещё позволяет минимизировать ущерб.

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

B>КАК ИМЕННО вы работаете со схемами? Прям вот ежедневная рутина.
Visual Studio + SQL Server Data Tools. Отдельный проект под БД.
Структура верхних папок такая же, как в SSMS. Внутри каждой есть папка со схемой, внутри схемы уже сами объекты.
Например:
./Tables/sec/users.sql — таблица sec.users
./Tables/sec/clients.sql — таблица sec.clients
./Tables/billing/payments.sql — таблица billing.payments
./Programmability/Stored Procedures/sec/getUserByID.sql — хранимка sec.getUserByID
...
Сами схемы определены в папке ./Security/Schemas/.

Можно и по другому структуру папок создать, но мне так удобнее/привычнее, а остальные ребята в команде не настоящие DB-лы и будут делать так, как я сказал.

B>Вы выбираете одну схему и в ней торчите весь день? Вы работаете сразу с 2-3 схемами?
Я работаю с функционалом. Т.е., с work item, user story, to-do item — как хочешь назови.
В общем, мне надо обеспечить какой-то кусок функционала приложения.

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

B>Удобно ли иметь тупо плоский список таблиц и фильтровать его по схемам?
В целом, мне удобна структура, которую я привёл выше + поиск по имени/части имени объекта. Было бы удобно ещё иметь поиск по коду, отфильтровывающий список файлов, как это сделано в VS Code, но и без него терпимо, в общем-то.

Правда, ты не циклись на таблицах так, т.к. что с ними-то работать? Один раз определил, да пару раз доработаешь, как новый функционал потребуется, да и всё. Больше работать будешь с DML, чем с DDL, ИМХО.

B>Если с двумя схемами я ещё разберусь, то распахивать дерево для десяти схем — это уже полный маразм и потеря производительности.
Чисто ИМХО — в этом убожестве в принципе работать маразм и потеря производительности. Сужу чисто по скриншотам, но как в этом говне работать, я не представляю. Там же невозможно работать с БД как с кодом...

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

B>Тут надо откатиться назад и вспомнить, что речь про программистов и БД — это вообще не их компетенция "взлом базы".
Это большое заблуждение.
Безопасность — это компетенция, размазанная по всем командам, замешанным в создании и эксплуатации продукта.

B>Не говоря о том, что если хацкер поимел доступ вообще к базе, пермишены по схемам уже мало чем помогут.
И это тоже заблуждение. Тебе уже сказали про это, в общем-то.

B>Ну и третий момент, знания по DBA. Далеко не все программисты могут "залезть и поменять права" на какую-то таблицу или схему.
А и не надо разработчику в БД лезть и менять права.

Вот что разработчику помнить надо — так это то, что безопасность продукта — забота коллективная. И что не надо требовать супер-прав на всё подряд только потому, что так тебе легче. Уровень сервера приложения — это, конечно, хорошо, но не надо себя лишать очень хорошо отлаженного и проверенного механизма обеспечения безопасности, думая, что свой самописный будет лучше, или, хотя бы, на уровне. Не будет. У тебя нет столько ресурсов, сколько у создателей основных РСУБД.

B>Меньше всего я хочу прыгать в отладчике кода "почему я не могу получить список городов" только из-за того, что где-то в БД небрежный товарищ забыл добавить прав.
Меньше всего, всё же, ты, наверное, хочешь потерять работу и получить плохую репутацию только из-за того, что тебе было лень предусмотреть в своём коде разграничение прав и на уровне БД в том числе и злоумышленник получил доступ сразу ко всему инстансу СУБД, т.к. ты попросил прав сисадмина для логина своего приложения, а потом случайно написал код, позволяющий банальный SQL Injection.

А попрыгать в отладчике на этом фоне так — мелочи жизни, поверь.