> Хотелось бы чего-то более элегантного. Кота в нарядной шапочке и вжух?

Что может быть более элегантным чем каскадный внешний ключ?

что-то типа CREATE TABLE "a" ( "id" serial primary key not null, "b_id" integer not null references "b"("id") on delete cascade ); CREATE TABLE "b" ( "id" serial primary key not null, FOREIGN KEY "b"("id") on delete cascade ); Короче, чтобы без лишних, ненужных полей :)

create table a (id integer primary key); create table b (id integer primary key); alter table a add constraint "a_fkey" foreign key (id) references b(id) on update cascade on delete cascade deferrable initially deferred; alter table b add constraint "b_fkey" foreign key (id) references a(id) on update cascade on delete cascade deferrable initially deferred;

begin; insert into a (id) values (42); insert into b (id) values (42); commit;вот так вставлять

@JWo1F

Не подскажете варианты как использовать elasticksearch для индексации баз в postgres?

Shaz, у нас отдельный демон, который пишет в эластик новые данные из ПГ

Shaz, у нас отдельный демон, который пишет в эластик новые данные из ПГ

Вы его сами писали? Или его можно найти где-то?

Сами написали, решенали "на коленке"

Данных немного, поэтому еще раз в 15 минут производим реиндекс на всякий случай

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

если там где-нибудь неструктурированные данные с произвольными ключами - там вообще беда будет

Коллеги, доброго дня, подскажите как можно реализовать блокировку пользователя после 5ти неудачных входов в систему за определенный период ( к примеру 10 минут ) ?

Коллеги, доброго дня, подскажите как можно реализовать блокировку пользователя после 5ти неудачных входов в систему за определенный период ( к примеру 10 минут ) ?

fail2ban

да.. про него же думал, но чего-то из коробочного нет ?

Коллеги, доброго дня, подскажите как можно реализовать блокировку пользователя после 5ти неудачных входов в систему за определенный период ( к примеру 10 минут ) ?

у postgrespro есть наработки. а так можете здесь поколдовать: https://github.com/postgres/postgres/blob/master/contrib/auth_delay/auth_delay.c

Использовать PAM?

Коллеги, доброго дня, подскажите как можно реализовать блокировку пользователя после 5ти неудачных входов в систему за определенный период ( к примеру 10 минут ) ?

получение пароля в процедурку обернуть

и в ней же update какой то колонки подсчета входов и т.п.

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

subj ясен, думал что-то есть чего не знаю, спасибо !

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

создается дополнительная цепочка с iptables под jail, где блокируются те, кто туда входит

если ip превысил попытки - добавляется туда

Народ, а как сделать связь one-to-many, но так, чтобы как только удалились все зависимые записи, удалялся и сам элемент? Например, у меня есть картинка, юзеры могут пересохранять ее к себе, но как только все ее удалили она должна уйти из БД.

разве что триггерами. Подсчитывать количество ссылок на запись в отдельном поле (one), как только станет 0 - удалять запись. При вставке в (many) инкрементить счетчик в (one)

Т.е. легче мне будет сделать уже на сервере :)

Еще вопрос: прочитал про массивы в pgsql, круто. Но как настроить, чтобы у меня массив чисел был связан с айдишниками в другой таблице? Типа references?

никак, это было, но выпилили из-за перформанса

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

никак, это было, но выпилили из-за перформанса

А можно посмотреть, где это было? Это прямо в мастере было или какой-нибудь Postgres Professional делал?

патч был, но не от постгреспро

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

да, патч был в 9.2 или 9.3. можно найти в мейлинг листах

патч был, но не от постгреспро

Вот здесь Саша Коротков рассказывал об этом в 2012 году http://profyclub.ru/docs/264

да, если кому интересно то вот описание в блоге 2ndquadrant http://blog.2ndquadrant.com/postgresql-9-3-development-array-element-foreign-keys/

Вот здесь Саша Коротков рассказывал об этом в 2012 году http://profyclub.ru/docs/264

Все бы хорошо, если бы не одно но... Всем нужны нормализованные данные

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

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

ммм? нормализация это боль

ммм? нормализация это боль

Это боль для etl/elt

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

если данные денормализованные то не надо тратить рессурсы системы на связывание данных. Это фундаменттально, а то что выше не читал.

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

если данные денормализованные то не надо тратить рессурсы системы на связывание данных. Это фундаменттально, а то что выше не читал.

А то что их читать надо тоннами при этом, расчет не берется?

Это все таки не колоночная бд

А то что их читать надо тоннами при этом, расчет не берется?

как правило ты их денормализуешь таким образом каким чаще всего и делаешь выборку...

всё зависит от того насколько вы это дермолизуете )

это ведь надо не с бухты барахты делать... это конкретный подход который решает конкретную проблемму

но это лучше чем 16 join... если конечно место есть

и write не страшен

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

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

нормализация не про место, а про решение задачи избыточности

нормализация не про место, а про решение задачи избыточности

это одно и то же

чё?

данные == место на диске

нету избыточных данных - лишнее место не занимается

Юр, представь базу кредитов выдали кредит человеку с паспортом Иванов Иван Иванович, как ты это будешь хранить в денормализованной базе?

А то что их читать надо тоннами при этом, расчет не берется?

наоборот

нету избыточных данных - лишнее место не занимается

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

Юр, представь базу кредитов выдали кредит человеку с паспортом Иванов Иван Иванович, как ты это будешь хранить в денормализованной базе?

давайте лучше пример с лайками. Один лайкнул надо проапдейтить у 1000

Юр, представь базу кредитов выдали кредит человеку с паспортом Иванов Иван Иванович, как ты это будешь хранить в денормализованной базе?

это тут причём? Никто не говорит что денормализуется всё. (разговор вообще не про это) Ну и вроде тебе нкто не мешает в одну таблицу поместить и паспорт и кредит и всё всё. (matview некую сделать)

давайте лучше пример с лайками. Один лайкнул надо проапдейтить у 1000

вот по этому для этого они не используют РСУБД

это тут причём? Никто не говорит что денормализуется всё. (разговор вообще не про это) Ну и вроде тебе нкто не мешает в одну таблицу поместить и паспорт и кредит и всё всё. (matview некую сделать)

все понятно, спасибо.

наоборот

Почему наоборот? Только если индекс читать, не много, как только надо вытащить более двух полей, это сразу чтение всех данных

вот по этому для этого они не используют РСУБД

Вот поэтому доводилось использовать РСУБД для этого ;)

не считая накладных расходов на work_mem всё работало отлично

все понятно, спасибо.

С добрым утром.

не считая накладных расходов на work_mem всё работало отлично

ну это смотря какая нагрузка... у меня то же всё в СУБД.

с этим не буду спорить

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

не считая накладных расходов на work_mem всё работало отлично

а Facebook к примеру так не может

в вк в мускуле такое хранят как-то вроде местами

(это к слову о нагрузке)

что fb что vk - штучные продукты, со своими костылями, что вы под одну гребенку всех зачесываете?

не такие уж и штучные, хотя со своми тараканами

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

Я всё же остаюсь на своём. Если ты убираешь избыточность данных то ты уменьшаяешь размер той информации что хранишь.

в плане субд там всё достаточно традиционно

Я всё же остаюсь на своём. Если ты убираешь избыточность данных то ты уменьшаяешь размер той информации что хранишь.

Ой, блин... рукалиТСо.жыпег

А повышение скорости запросов при денормализации - это такое вот из мыскля приползло несколько-летней давности.

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

Это повышения формирование таблицы фактов

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

Я всё же остаюсь на своём. Если ты убираешь избыточность данных то ты уменьшаяешь размер той информации что хранишь.

Кстати. Денормализованная таблица меньше в объеме, чем нормализованные данные. Догадайся, почему.

Кстати. Денормализованная таблица меньше в объеме, чем нормализованные данные. Догадайся, почему.

Ну ка ну ка, почему же?

Почему наоборот? Только если индекс читать, не много, как только надо вытащить более двух полей, это сразу чтение всех данных

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

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

При джойна я прочитаю индекс, а не скан всей таблицы

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

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

для postgres это то же всё работает, надо просто понимать какие данные ты часто запрашиваешь и как пишешь. Это всегда лучше join.

Кстати. Денормализованная таблица меньше в объеме, чем нормализованные данные. Догадайся, почему.

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

При джойна я прочитаю индекс, а не скан всей таблицы

а разница? всё равно надо приличное колличество лишних действий сделать

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

если данные распространяются только в одну сторону (грубо говоря, строится тот самый mat.view на основе SSOT), то никаких проблем нет кроме задержек в обновлении вывода

а разница? всё равно надо приличное колличество лишних действий сделать

Это каких? Создать индекс и написать джойн?

если данные распространяются только в одну сторону (грубо говоря, строится тот самый mat.view на основе SSOT), то никаких проблем нет кроме задержек в обновлении вывода

вы все про скорость, а могу ли я доверять данным в mat.view?

При джойна я прочитаю индекс, а не скан всей таблицы

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