Ребят, нужна небольшая статистика/мнения по поводу одной фичи. Поделитесь пожалуйста опытом!
В 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>Спрашиваю здесь, потому что это именно прикладной вопрос для программистов, насколько "разветвлённые" у них базы и есть ли смысл заморачиваться с нэймспэйсами.

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

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