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

такую мысль:
Планируется много схем (с большим количеством таблиц), которые будут создаваться динамически, но иметь одинаковый префикс в названиях (group_<id>), нужно чтобы структура схем была индентичной. Возможно ли как-то при создании схемы унаследовать структуру от другой? И еще вопрос, возможно ли при изменении структуры какой-то таблицы в одной из схем, изменить сразу во всех остальных?

А зачем тебе схемы эти? Так-то Идиотская идея.

Будет схема с какой-то информацией из разных чатов. Например схема чата #1, в ней лежит таблица users, users_activity и тд. И таких чатов много

ИДиотская идея. Ид чата в PK таблиц — и ноль проблем.

то есть одна таблица на все чаты, но отдельная колонка с ид чата?

Как то очень похоже на ещё одну попытку сделать плохо

да

Не одна таблица конечно, а один набор связанных таблиц.

Возможно. Поэтому хочу получить информацию у знающих. Буду рад советам

А в плане производительности при выборке данных такой подход не хуже?

Не хуже.

Благодарю

Вообще, что-то в БД создавать динамически, во время работы системы - это антипаттерн.

Спасибо, оказалось всё намного проще

даже темповые таблицы?

Временные можно

а таблицы по годам?

нет

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

Нет, это не надо делать, это антипаттерн. Это не обычная задача а задача типа "насрать коллегам".

то есть ты серьезно сейчас предлагаешь хранить все данные за все время в одной таблице, я правильно понял?

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

попробуй посмотреть на https://www.postgresql.org/docs/8.4/rowtypes.html и/или https://www.postgresqltutorial.com/postgresql-user-defined-data-types/

а если данных очень много?

тогда, очевидно, нужно страдать

а как иначе ? ну если есть основания что нужно как то разделить, есть партиционирование ) в совсем сложных случаях уже неиспользуемые данные можно вынести в некий архив

А если данных очень много, то надо переходить на вертику, Virtuoso, Sybase IQ или Терадата. И там это ТОЖЕ будет в одной таблице.

А сколько у тебя данных в таблице - это "много" ?

в строках сотни миллионов-миллиарды

От миллиарда - надо в columnstore, да

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

Заказчик естественно.

ну глупость же, любая современная бд тянет миллиарды записей на изян

волшебный принц на белом коне прискачет оплатить вам касандру, чтоб я так жил, а

Ну это всё говнотехнологии... Ладно.

Партицирование всё ж позволяет хранить данные в пределах одной БД и обрабатывать их одним запросом.

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

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

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

Когда начались проблемы с операцыями поддержки -- там vacuum full, create index, вот это всё -- то шардить. Когда есть мысль hotset поместить на SSD, а остальное на HDD -- тожэ шардить. Но это тожэ всё достаточно неприятно и в среднем работает медленнее, чем без шардов.

Пффф! Копейки. Если небольшой размер строки (в пределах 100 байт) -- то это жалкие 100GB данных, по сегодняшним временам очень невеликий размер. Часто в RAM влезает, кстати.

И да, columnstore абсолютно ортогонален количеству строк. Можэт быть база на 10к строк, которую лучшэ пихнуть в columnstore, потому, что идеально подходит и незачем ориентироваться на postgres. Можэт быть распределённая база на десять триллионов строк, у которой реальный выбор -- между Postgres, Oracle, DB/2, DB/z, поскольку нужна надёжность и откатанность технологий, к тому жэ columnstore не даст вообще никаких преимуществ из-за особенностей предметной области.