и как расчитать размер walов? они ведь генерятся сильно по-разному в зависимости от нагрузки на базу.

дык это самая сложная часть, как и расчет размера изменений файлов данных

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

дык это самая сложная часть, как и расчет размера изменений файлов данных

:) :(

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

умножаем на 2, а лучше на 4

на правах рекламы, pg_probackup не смотрели?

нет. пока не смотрел. ну то есть доку я на него почитал, arman я видел (я так понял это просто доработанный arman?)

вопрос - а он в этой https://postgrespro.ru/products/1c/supported версии доступен?

отдельным пакетом

вот тут инструкция по установке: https://github.com/postgrespro/pg_probackup

о! не знал что есть отдельная репа

а что ещё в отдельных репках так лежит?

затрудняюсь сказать

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

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

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

https://github.com/postgrespro так вот же

да я туда конечно уже посмотрел.

на правах рекламы, pg_probackup не смотрели?

> Создание копий с удалённого сервера в настоящее время не поддерживается. вот это печаль

https://github.com/postgrespro так вот же

я про пакетные репозитории =)

> Создание копий с удалённого сервера в настоящее время не поддерживается. вот это печаль

да, есть такое. На данный момент только через сетевую шару

Добрый день Кто может подсказать Планирую создать базу данных Таблицы users И user_type Плюсом для каждого user_type еще таблицы students managers Теперь вот в чем вопрос. Как это всё связать?

а чем отличается user от student, a student от managers?

кажется, ты вместо "колонка" используешь "новая таблица"

username | is_manager | is_student должно хватить?

юзер содержит только общие поля для этих типов а student и manager поля которые тольо для этих подходят

в общем решение подсмотрел вот тут но не очень пойму, как в таком случае взаимодейтсвуют таблицы students и instructors с таблицей user_types https://dba.stackexchange.com/questions/75792/multiple-user-types-db-design-advice

в общем решение подсмотрел вот тут но не очень пойму, как в таком случае взаимодейтсвуют таблицы students и instructors с таблицей user_types https://dba.stackexchange.com/questions/75792/multiple-user-types-db-design-advice

А зачем вам вообще user_types, в таком случае?

а как? я же где-то должен определить возможные user types

я никак не могу представить подобное у себя в голове но задача вот такая таблица users содержит поля общие для всех таблица user_type содержит возможные типы пользователей и их id таблица students содержит поля которые должны быть только у пользователя с типом students таблица managers содержит только поля которые должны быть у пользователя с типом managers

а как? я же где-то должен определить возможные user types

А зачем? У вас ведь всё равно по таблице для каждого типа (students, instructors и т.п.)... или нет?

Таблицы для каждого типа есть Но общее для этих типов вынесено в отдельную

Т.е. у вас что-то вроде: CREATE TABLE user_types(user_type_id text PRIMARY KEY, description text NOT NULL); CREATE TABLE users(user_id serial PRIMARY KEY, user_type_id text NOT NULL REFERENCES user_types, name text NOT NULL); CREATE TABLE students(student_id int PRIMARY KEY REFERENCES users(user_id), attr1 text, attr2 numeric); CREATE TABLE instructors(student_id int PRIMARY KEY REFERENCES users(user_id), attr1 text, attr2 numeric); ?

я делаю через орм но в целом выглядит похоже

Ну а вопрос-то в чём? ;)

как оно будет работать? как оно узнает, что этот пользователь именно students или instructors, если у них есть только user_id

как оно будет работать? как оно узнает, что этот пользователь именно students или instructors, если у них есть только user_id

Если бы не было поля user_type_id в таблице users —- по наличию записи в соответствующей таблице. Если оно есть, то по его значению.

как оно будет работать? как оно узнает, что этот пользователь именно students или instructors, если у них есть только user_id

яхз) логическая связь или есть, или нету https://eax.me/database-design/

это джанго что ли? такое ощущение что вопросы все таки про пайтон а не постгрес

Если бы не было поля user_type_id в таблице users —- по наличию записи в соответствующей таблице. Если оно есть, то по его значению.

А как связаны между собой students и usertypes?

это джанго что ли? такое ощущение что вопросы все таки про пайтон а не постгрес

это фласк, но вопрос в целом про базы данных, а не их реализацию

то есть..

А как связаны между собой students и usertypes?

покажи примеры рядов данных в таблицах и сразу все понятно станет

я никак не могу представить подобное у себя в голове но задача вот такая таблица users содержит поля общие для всех таблица user_type содержит возможные типы пользователей и их id таблица students содержит поля которые должны быть только у пользователя с типом students таблица managers содержит только поля которые должны быть у пользователя с типом managers

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

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

А как связаны между собой students и usertypes?

Никак. Модель-то не без недостатков. ;( Делают ещё так: CREATE TABLE users( user_id serial, user_type_id text NOT NULL REFERENCES user_types, name text NOT NULL, PRIMARY KEY (user_id, user_type_id) ); CREATE TABLE students( student_id int PRIMARY KEY, user_type_id text NOT NULL CHECK (user_type_id = 'student'), attr1 text, attr2 numeric, FOREIGN KEY (student_id, user_type_id) REFERENCES users(user_id, user_type_id) ); Но, по-моему, это как-то туповато. :(

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

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

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

Кто "оно" (узнаёт)?

допустим я сделаю запрос где захочу получить информацию по пользователю с id 1 и он - students значит помимо полей из users у него должны быть поля из students вот это я не пойму

@uspen2018, Игорь, у вас синхронная репликация используется? У меня сейчас задача — клястер отказоустойчивый замутить, но одна нода нужна синхронная. Бизнес, однако. Вот выбираю между патронами и коросинк+пейсмейкер

Если вы делаете запрос по users, вы, очевидно, можете либо: . Получить поля только из users. . Получить поля из _всех_ связанных таблиц: LEFT JOIN каждой, NULL для нерелевантных (потому что, действительно "откуда ему знать"? ;) ). И вы не можете в реляционной СУБД получить в результате запроса записи, где для каждой набор полей отличается.

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

что сохранили — то и достать можно будет все просто

ну если спросишь из users то получишь только из users

если сделаешь подзапросы или джойны — поулчишь еще и то что прикрутил

тут магии нет, что спросишь то и получишь

на алхимии я уже не помню толком, вроде можно джойнить прямо, а можно префетч делать

на джанго орм есть select_related

Session.query(User, Student).filter(User.id=Student.user_id).all() например

вот так на алхимии можно заджойнить

да это не проблема меня смущает немного другое щас, я попробую придумать, как это объяснить

СУБД так спроектирована что она не будет ничего знать пока ты пальцем не ткнешь. пока не пропишешь что именно это поле будет ключем на форейн тейбл

@uspen2018, Игорь, у вас синхронная репликация используется? У меня сейчас задача — клястер отказоустойчивый замутить, но одна нода нужна синхронная. Бизнес, однако. Вот выбираю между патронами и коросинк+пейсмейкер

Привет, Миша! Да, используем. Не надо коросинков ) Я бы рекомендовал Patroni. Там (внезапно) есть возможность строгого синхронного режима. То есть если синхронная реплика недоступна, то мастер встает. Еще я б рекомендовал сделать так. Включить синхронную репликацию и где не надо синхронных коммитов ставить SET LOCAL synchronous_commit TO OFF

Строго синхронный режим,как раз не надо. Нужен синк+асинк и без лишнего кодирования. Коросинк+пейсмейкеп может синк-ноду в асинк режим переводить при проблемах сети. Патроны такое могут?

СУБД так спроектирована что она не будет ничего знать пока ты пальцем не ткнешь. пока не пропишешь что именно это поле будет ключем на форейн тейбл

Кае для подобной базы вносить записи? То есть я сам смотрю, если он студент, то также добавляю его в таблицу стьюдент? Или как Я не пойму как мне взаимодействовать с этим

Строго синхронный режим,как раз не надо. Нужен синк+асинк и без лишнего кодирования. Коросинк+пейсмейкеп может синк-ноду в асинк режим переводить при проблемах сети. Патроны такое могут?

Да, по умолчанию режим не строгий, если не будет синхронной реплики с мастером ничего не станет

Кае для подобной базы вносить записи? То есть я сам смотрю, если он студент, то также добавляю его в таблицу стьюдент? Или как Я не пойму как мне взаимодействовать с этим

Вы сначала вставляете в таблицу users, потом в соответствующую таблицу (students или instructors). Итого, 2 INSERT-а. Вообще, "прозрачно" на уровне СУБД это сделать не так-то легко, мне кажется.

Но такой вариант будет нормальным? Просто мне хотелось бы правильно сделать, с точки зрения профессионалов

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

Но такой вариант будет нормальным? Просто мне хотелось бы правильно сделать, с точки зрения профессионалов

Нормальный он или нет, зависит от задачи. ;) Т.е. это вот всё вам вообще зачем? То есть, почему не просто отдельные таблицы students, instructors, managers и т.п.?

- получить юзера - - если у него юзер_тайп == студент, то добавить в студентов запись - - если нет то пропускаем - если юзера нет то завести его

ну с голым SQL это замучает, а с орм можно лаконичнее

ну с голым SQL это замучает, а с орм можно лаконичнее

Может быть и лаконичнее, только вот надёжно работать будет только через эту ORM...

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

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

Нормальный он или нет, зависит от задачи. ;) Т.е. это вот всё вам вообще зачем? То есть, почему не просто отдельные таблицы students, instructors, managers и т.п.?

Я думал сделать так Но тогда получаются таблицы с почти идентичными записями Такой вариант мне показался более удобным

- получить юзера - - если у него юзер_тайп == студент, то добавить в студентов запись - - если нет то пропускаем - если юзера нет то завести его

Не совсем так В таблицах базы данных ничего нет И я сам начну ее заполнять с нуля

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

можно вообще сначала заполнить юзерс а потом типа -

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

Почему "не продумали"? Это вполне реальная задача (не такая уж частая, да). "Корень" её в том, что один объект реального мира _нужно_ рассматривать как относящийся в разным типам. Например, быки и коровы. Показателям "надой" или "кол-во телят" нечего делать в таблице "быки". А вот, например, выполненные привики (и т.п.) относятся к животным, независимо от пола.

можно инсерт сделать уже когда юзеры будут готовы, просто инсерт в студентс из селекта по криетрию user_type==student или что там

Я думал сделать так Но тогда получаются таблицы с почти идентичными записями Такой вариант мне показался более удобным

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

Почему "не продумали"? Это вполне реальная задача (не такая уж частая, да). "Корень" её в том, что один объект реального мира _нужно_ рассматривать как относящийся в разным типам. Например, быки и коровы. Показателям "надой" или "кол-во телят" нечего делать в таблице "быки". А вот, например, выполненные привики (и т.п.) относятся к животным, независимо от пола.

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

Ко мне будет обращаться фронт и передавать некоторые данные Которые я должен буду сохранить Эти данные будут разные для студентов и менеджеров

Ко мне будет обращаться фронт и передавать некоторые данные Которые я должен буду сохранить Эти данные будут разные для студентов и менеджеров

Это не обоснование, IMHO. Вот если бы вам нужно было где-то ссылаться иногда _только_ на студентов ( student_groups(group_id, student_id REFERENCES students, ... ) ), иногда только на менеджеров, а иногда на пользователей независимо от типа, тогда бы стоило что-то усложнять.

Ладно, я понял Но мне просто такое решение не понравилось

Да, по умолчанию режим не строгий, если не будет синхронной реплики с мастером ничего не станет

Стоп, немного изменю вопросы: вот смотри, конфигурация следующая: мастер, синк-реплика и асинк-реплика. Такое возможно? Падает синк-реплика, ну или тормозить начинает. В этом случае асинк-реплика становится синк-репликой, если сеть позволяет, если обе тормозят, то пусть обе будут асинк-репликами. Такое возможно?

> мастер, синк-реплика и асинк-реплика. Такое возможно? Да, конечно Асинк становится синк Но всегда должна быть синк реплика. То есть если после сбоя асинк догонится, то ПГ сделает ее синк репликой

Так же при желании можно через Patroni API на лету менять тип репликации

Через API - это уже рукоблудие. А так, спасибо, понЕл. Буду думать дальше.

Хмм А если я сам буду распределять между managers и students, то зачем мне таблица user_type?

Хмм А если я сам буду распределять между managers и students, то зачем мне таблица user_type?

что б потом собрать обратно правильно?

В плане? Ведь если я буду знать Что все пользователи с user_type = students(1) - студенты

а, это видимо такая небольшая справочная таблица на три записи?..

В плане? Ведь если я буду знать Что все пользователи с user_type = students(1) - студенты

Она нужна, если у вас есть какие-то дополнительные данные про сами типы. Иначе хватит и констант (или enum).

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

На фронте будет такой Но он мне будет присылать 1, 2, 3 Три типа пользователя

ну а на фронт он откуда попадет?