Size: a a a

pgsql – PostgreSQL

2020 July 16

YS

Yaroslav Schekin in pgsql – PostgreSQL
Evgeny Makarov
хотелось бы понять каким образом скажем Clickhouse не удовлетворяет конкретному кейсу. деталей по кейсу не хватает чтобы сказать что-либо
Почему не смогли наладить загрузку данных в тот же BQ - открытый вопрос
Если Вы предлагаете заменить PostgreSQL на Clickhouse — про этот case мы почти ничего (относящегося к этому вопросу) не знаем. Если же Вы предлагаете заменить BigQuery на Clickhouse — у них, скорее всего, будут ровно те же проблемы.
источник

EM

Evgeny Makarov in pgsql – PostgreSQL
Yaroslav Schekin
Если Вы предлагаете заменить PostgreSQL на Clickhouse — про этот case мы почти ничего (относящегося к этому вопросу) не знаем. Если же Вы предлагаете заменить BigQuery на Clickhouse — у них, скорее всего, будут ровно те же проблемы.
никто не предлагал PG заменять
вынести аналитику в CH предлагается
я очень поверхностно и давно работал с BQ, не могу сказать точно на данный момент, но инструментарий загрузки данных в CH кажется, гораздо шире
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Yelena Bunina
тогда долгие запросы падают с ошибкой о протухших таплах. репликация отстает. запрос идет больше часа
разве для вас критично что репликация отстаёт? Ведь вы всё равно с определенной периодичностью запрашиваете полный объём данных из ПГ. Чуть позже просто данные будут получены и попадут в BQ
источник

R

Roman in pgsql – PostgreSQL
Нормальная схема базы?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Evgeny Makarov
никто не предлагал PG заменять
вынести аналитику в CH предлагается
я очень поверхностно и давно работал с BQ, не могу сказать точно на данный момент, но инструментарий загрузки данных в CH кажется, гораздо шире
А, понятно. Я тоже достаточно давно с ним работал, тоже не могу сказать по инструментарию загрузки.
источник

АТ

Александр Тарасов... in pgsql – PostgreSQL
Roman
Нормальная схема базы?
у каждого пользака только 1 док?
источник

R

Roman in pgsql – PostgreSQL
Александр Тарасов
у каждого пользака только 1 док?
Да
источник

АТ

Александр Тарасов... in pgsql – PostgreSQL
один скилл и одно образование, а еще знает только один язык
источник

R

Roman in pgsql – PostgreSQL
Нет. Там где звездочка там многие. Там все связи многие кроме докуиента.
Еще вопрос. Нужно еще делать свящи между другими таблицами например скилы и образование?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Roman
Нет. Там где звездочка там многие. Там все связи многие кроме докуиента.
Еще вопрос. Нужно еще делать свящи между другими таблицами например скилы и образование?
И что, "звёздочка" — это магия? ;) Таблицы-то всё равно неправильные, на первый взгляд.
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Roman
Нет. Там где звездочка там многие. Там все связи многие кроме докуиента.
Еще вопрос. Нужно еще делать свящи между другими таблицами например скилы и образование?
как в колонку users.skill_id добавить 3 скила?
источник

R

Roman in pgsql – PostgreSQL
Я делал в редакторе dbuilder
источник

EM

Evgeny Makarov in pgsql – PostgreSQL
Roman
Нормальная схема базы?
вместо varchar лучше что-то другое выбрать
источник

R

Roman in pgsql – PostgreSQL
Evgeny Makarov
вместо varchar лучше что-то другое выбрать
Например?
источник

EM

Evgeny Makarov in pgsql – PostgreSQL
ну или иначе будете постоянно следить за длиной
источник

R

Roman in pgsql – PostgreSQL
Victor Yegorov
как в колонку users.skill_id добавить 3 скила?
Сделать 3 скила логично же и связать
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Roman
Я делал в редакторе dbuilder
Стоит показывать реальные схемы (CREATE TABLE) вместо диаграмм в неведомой нотации, IMNSHO.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Roman
Например?
text
источник

EM

Evgeny Makarov in pgsql – PostgreSQL
а сорри у вас не лимитированный
источник

VY

Victor Yegorov in pgsql – PostgreSQL
не вижу ничего против varchar, если действительно нужно ограничивать длину. зачастую даже полезно… без ограничений — text проще, т.к. писать меньше
источник