она правда не про постгрес

ой а можно я вакансию опубликую

Можно Машку за ляжку! Козу на возу!

:D

Чегой-то меня на старое, доброе, вечное потянуло...

но вообще конечно слабовата тема для пятничного срача

Это вообще не для этого чатика тема. А где сетевики/системщики крутые обитают, ага. :P

она правда не про постгрес

А можно, она станет про постгрес?)

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

с паролем у суперюзера

вот это все

Не светить postgresql наружу

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

Господи парольная авторизация на сисяш

Стоит ли юзать json поля в базе. В pgsql эта тема я смотрю сильно развита, есть jsonb с кучей прикольных штук. Может есть хорошая статейка на эту тему? В моем случае переводы полей в jsonb.

Стоит ли юзать json поля в базе. В pgsql эта тема я смотрю сильно развита, есть jsonb с кучей прикольных штук. Может есть хорошая статейка на эту тему? В моем случае переводы полей в jsonb.

А с какой целью?

А с какой целью?

С целью увеличения скорости доступа к переводам.

С целью увеличения скорости доступа к переводам.

Расскажите подробнее. Что такое "переводы полей", что у Вас хранится в поле? Документ?

Расскажите подробнее. Что такое "переводы полей", что у Вас хранится в поле? Документ?

{"ru": "руская версия", "uk": "<p>украинская версия</p>\n"} А вообще может быть огромная куча текста. Иными словами статья, а её переводы хранятся здесь же в json поле.

А ищите вы их как? По идентификатору статьи? Мне кажется, что вряд ли JSONb будет быстрее, чем просто: translation(article_id, language, text).

а вам когда-нибудь нужны два языка одновременно?

Тут как раз больше заморочек, некоторые говнороутеры не могут пропускать gre, некоторые говнопровайдеры могут не пропускать gre..

Вы gre тунель в чистом виде пускаете, зачем так переживаете?

Вы gre тунель в чистом виде пускаете, зачем так переживаете?

Никак не пускаем, отказались от этой затеи

Привет всем! Есть такая таблица Table: id - автоинкремент date_time - текущее время ...... тут еще всякие поля. Вставляю данные: INSERT INTO Table SELECT now() .... тут ещё всякие значения. Получаю ошибку: столбец "id" имеет тип integer, а выражение - timestamp with time zone (символ 752) Ожидаю, что автоинкремент будет автоматически нкрементироваться. Если это не верное ожидание, то что надо вставлять в id?

nsert into table (date_time) ... ?

nsert into table (date_time) ... ?

У меня вставляется результат другого запроса: INSERT INTO Table SELECT now(), cons.amount FROM cons

INSERT INTO Table (date_time, amount) SELECT now(), cons.amount FROM cons

INSERT INTO Table (date_time, amount) SELECT now(), cons.amount FROM cons

а, да, пробую.

INSERT INTO Table (date_time, amount) SELECT now(), cons.amount FROM cons

Спасибо, помогло! )

Как назвать таблицу в которой хранятся связки. Типа user_id segment_id

user_segment и назови

user_segment и назови

...s

Встречайте mysql пользователя

мое вам сочувствие

мое вам сочувствие

Тонко

и аватарка в тему)

Всем привет. У меня казалось бы простая задача, но что-то не могу сообразить как лучше зайти. Есть дерево категорий огромной вложенности. Нужно по определенным параметрам (where), с сортировкой, лимитами и оффсет, вывести, допустим, 5 записей категории 1. Для каждой из 5 записей категории 1 сделать выборку по параметрам 5 дочерних элементов, также с сортировкой - назовем это категорией 2. Если для записи из категории 1 не находится пары в категории 2 (например на прошла по where), то эта запись (из категории 1) не должна участвовать в запросе. Далее также выбираем категории 3, 4, 5. Если мы составили дерево вплоть до 4 категории, но на 5 мы не нашли элементов по параметрам - вся ветка не учитывается. Надеюсь понятно объяснил. При этом очень важно иметь возможность нормально сортировать данные, делать offset и limit. Пытался делать JOINами и через WITH - все получается и с приемлемой скоростью. Но проблема в том, что мне нужно для каждого уровня задавать свои лимиты, сортировку, отступ, а не для всего результата выборки в целом. Куда в такой ситуации смотреть?

Приветствую!

Сложно по такому описанию что-то конкретное посоветовать.

Могу только сказать, что ORDER BY, LIMIT и OFFSET можно делать не только в конце, но также и внутри WITH, а также вообще любого подзапроса.

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

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

Всем привет. У меня казалось бы простая задача, но что-то не могу сообразить как лучше зайти. Есть дерево категорий огромной вложенности. Нужно по определенным параметрам (where), с сортировкой, лимитами и оффсет, вывести, допустим, 5 записей категории 1. Для каждой из 5 записей категории 1 сделать выборку по параметрам 5 дочерних элементов, также с сортировкой - назовем это категорией 2. Если для записи из категории 1 не находится пары в категории 2 (например на прошла по where), то эта запись (из категории 1) не должна участвовать в запросе. Далее также выбираем категории 3, 4, 5. Если мы составили дерево вплоть до 4 категории, но на 5 мы не нашли элементов по параметрам - вся ветка не учитывается. Надеюсь понятно объяснил. При этом очень важно иметь возможность нормально сортировать данные, делать offset и limit. Пытался делать JOINами и через WITH - все получается и с приемлемой скоростью. Но проблема в том, что мне нужно для каждого уровня задавать свои лимиты, сортировку, отступ, а не для всего результата выборки в целом. Куда в такой ситуации смотреть?

Вложенные запросы не?

Вложенные запросы не?

думаю сейчас попробовать зайти через EXISTS, но придется тогда в несколько запросов делать наверное, если вообще получится. данные объемные, неясно что выйдет. или вы другое что-то имели ввиду?

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

это было бы хорошее решение, но дело в том, что данные нужны от каждого уровня

А потом из джойнить

И неизвестно сколько и чего нужно будет?

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

И неизвестно сколько и чего нужно будет?

к сожалению нет

Может есть смысл процедуру?

И внутри ее на каждом шаге отрезать лишнее

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

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

Может есть смысл процедуру?

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

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

узлы на определенном уровне можно сделать. есть поле level, по нему ограничиваю, чтобы отсечь совсем лишнее

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

Мне кажется, что процедура упростит. А дальше, если увидите возможность упрощения, то оформите

Мне кажется, что процедура упростит. А дальше, если увидите возможность упрощения, то оформите

спасибо за совет, попробую с ними разобраться

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

Или кол-во join-ов заранее не известно?

может потребоваться для 5 категорий вывести 15 подкатегорий и для них 10 подподкатегорий. и т.д.

Или кол-во join-ов заранее не известно?

если вопрос об этом

Ну я могу ещё предложить тогда после этих join-ов сделать нумерацию каждого уровня. Видимо, если у тебя 5 уровней вложенности, то нужно 5 раз нумерацию сделать в каждом уровне, используя оконные функции. После нумерации профильтровать для первого уровня на <= 5, для второго - 15, 3-его - 10

Большой запрос получится, не бойся. С бизнес логикой, видимо, часто так

спасибо, попробую и этот вариант

Есть ли какой-нибудь смысл делать из индекса частичный, добавив условие на not null, по индексируемому полю?

если там есть очень много нуллов - почему нет

Ну я могу ещё предложить тогда после этих join-ов сделать нумерацию каждого уровня. Видимо, если у тебя 5 уровней вложенности, то нужно 5 раз нумерацию сделать в каждом уровне, используя оконные функции. После нумерации профильтровать для первого уровня на <= 5, для второго - 15, 3-его - 10

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

Почему многие используют для первичного ключа id int а не serial?

Почему многие используют для первичного ключа id int а не serial?

И эти многие... кто они? ;) Кроме шуток, может быть, идентификаторы объектов этих отношений задаются извне и являются целыми числами?

Чат почитал и сделал вывод

а ты посмотри во что сериал превращается

Чат почитал и сделал вывод

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

А, ещё может быть cross-table sequence, но тогда он будет сначала создан, а потом всё равно указан в default при объявлении PK.

Почему многие используют для первичного ключа id int а не serial?

сделай колонку serial и посмотри её тип

Почему многие используют для первичного ключа id int а не serial?

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

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

Было написано, что уровней 5 штук. После 5 джойнов все уровни в одной строке. Или вопрос какой-то другой?

Что происходит?))