RL
Да, только что вспомнил про regexp)
Похоже. что как то так
WHERE brand REGEXP '[A-Za-z0-9]*'
WHERE brand REGEXP '[A-Za-z0-9]*'
Size: a a a
2021 January 11
АЛ
зачем он вам?!
Например делать fk на секционированную таблицу
YS
Например делать fk на секционированную таблицу
https://t.me/pgsql/275125
На практике когда такое нужно, вот в чём вопрос.
На практике когда такое нужно, вот в чём вопрос.
SG
Yaroslav Schekin
https://t.me/pgsql/275125
На практике когда такое нужно, вот в чём вопрос.
На практике когда такое нужно, вот в чём вопрос.
Да те же таблицы orders и order_items. Странно в каждую колу и чизбургер пихать ещё и штат.
YS
Да те же таблицы orders и order_items. Странно в каждую колу и чизбургер пихать ещё и штат.
И ключи у них (order_id) и (order_id, item_id / line_id) или что-то в этом роде, нет?
Откуда другие уникальные индексы?
Откуда другие уникальные индексы?
SG
Yaroslav Schekin
И ключи у них (order_id) и (order_id, item_id / line_id) или что-то в этом роде, нет?
Откуда другие уникальные индексы?
Откуда другие уникальные индексы?
Ну да. orders(order_id PK) , order_items (item_id PK, order_id FK)
YS
Ну да. orders(order_id PK) , order_items (item_id PK, order_id FK)
Ну так и в чём проблема? Их можно партиционировать по этим ключам, и FK тут работают.
SG
Yaroslav Schekin
Ну так и в чём проблема? Их можно партиционировать по этим ключам, и FK тут работают.
Я не могу придумать ЗАЧЕМ их партиционировать по этим суррогатным ключам. А вот по дате заказа или по региону - вполне нужно.
YS
Я не могу придумать ЗАЧЕМ их партиционировать по этим суррогатным ключам. А вот по дате заказа или по региону - вполне нужно.
Как обычно — для того, чтобы облегчить maintenance.
Ни дата заказа, ни регион не являются уникальными ключами, поэтому как-то не относятся к обсуждению, нет?
Ни дата заказа, ни регион не являются уникальными ключами, поэтому как-то не относятся к обсуждению, нет?
Ss
всем привет, помогите как на триггер поставить такое условие, ошибка заключается в том что нельзя в триггере подзапросы использовать CREATE TRIGGER counter
AFTER INSERT ON status
WHEN(now() - (select last_dt from last_dt where id='1')> INTERVAL '24h')
EXECUTE PROCEDURE count_actives();
AFTER INSERT ON status
WHEN(now() - (select last_dt from last_dt where id='1')> INTERVAL '24h')
EXECUTE PROCEDURE count_actives();
YS
всем привет, помогите как на триггер поставить такое условие, ошибка заключается в том что нельзя в триггере подзапросы использовать CREATE TRIGGER counter
AFTER INSERT ON status
WHEN(now() - (select last_dt from last_dt where id='1')> INTERVAL '24h')
EXECUTE PROCEDURE count_actives();
AFTER INSERT ON status
WHEN(now() - (select last_dt from last_dt where id='1')> INTERVAL '24h')
EXECUTE PROCEDURE count_actives();
Проверяйте это условие внутри триггерной функции.
Ss
Мне нужно чтобы триггер выполнялся ежедневно в одно и то же время, если в функцию добавлю не сработает
YS
Мне нужно чтобы триггер выполнялся ежедневно в одно и то же время, если в функцию добавлю не сработает
Так при чём тут вообще триггер? Тут нужно чем-то запускать задание по расписанию, по идее — cron или pg_cron и т.п.
Ss
Задание такое
YS
Задание такое
Какое "такое"? Триггерами Вы это не решите, вот и всё.
Ss
А если использовать pg agent ?
Ss
Создайте триггер, который ежедневно считает количество активностей каждого пользователя за определенное время:
активность в приложении с 06:00 до 18:00 (дневное время);
активность в приложении с 18:01 до 05:59 (вечернее время).
Под активностью подразумеваются любые действия пользователя (не администратора) в приложении.
активность в приложении с 06:00 до 18:00 (дневное время);
активность в приложении с 18:01 до 05:59 (вечернее время).
Под активностью подразумеваются любые действия пользователя (не администратора) в приложении.
YS
А если использовать pg agent ?
Так он аналог того, что я посоветовал выше.
Ss
проще крон использовать?
YS
Создайте триггер, который ежедневно считает количество активностей каждого пользователя за определенное время:
активность в приложении с 06:00 до 18:00 (дневное время);
активность в приложении с 18:01 до 05:59 (вечернее время).
Под активностью подразумеваются любые действия пользователя (не администратора) в приложении.
активность в приложении с 06:00 до 18:00 (дневное время);
активность в приложении с 18:01 до 05:59 (вечернее время).
Под активностью подразумеваются любые действия пользователя (не администратора) в приложении.
Мне кажется, что тут задача либо криво сформулирована, либо Вы её неправильно понимаете.
Это можно прочитать так, что триггер просто должен поддерживать summary table вида (user_id, date, is_morning, total_actions) или что-то в этом роде.
Это можно прочитать так, что триггер просто должен поддерживать summary table вида (user_id, date, is_morning, total_actions) или что-то в этом роде.