Всем привет! Подскажите тузлу, которая позволяет строить планы запросов как студия MS SQL, только для больших процедур, потому как студия не отображает полностью план процедуры.

ребят, правильный ли запрос? DELETE l1 FROM leads l1 LEFT JOIN statuses s1 ON l1.status_id = s1.id, leads l2 LEFT JOIN statuses s2 ON l2.status_id = s2.id WHERE l1.id > l2.id AND l1.phone = l2.phone AND s1.pipeline_id = s2.pipeline_id нужно удалить из leads все с одинаковым phone и заджойненным pipeline_id из statuses, кроме самого первого из повторных

ребят, правильный ли запрос? DELETE l1 FROM leads l1 LEFT JOIN statuses s1 ON l1.status_id = s1.id, leads l2 LEFT JOIN statuses s2 ON l2.status_id = s2.id WHERE l1.id > l2.id AND l1.phone = l2.phone AND s1.pipeline_id = s2.pipeline_id нужно удалить из leads все с одинаковым phone и заджойненным pipeline_id из statuses, кроме самого первого из повторных

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

добрый день)

добрый, dba-user

Всем привет! Подскажите тузлу, которая позволяет строить планы запросов как студия MS SQL, только для больших процедур, потому как студия не отображает полностью план процедуры.

Ты бы указал на СУБД, у всех СУБД планы разные.

ребят, правильный ли запрос? DELETE l1 FROM leads l1 LEFT JOIN statuses s1 ON l1.status_id = s1.id, leads l2 LEFT JOIN statuses s2 ON l2.status_id = s2.id WHERE l1.id > l2.id AND l1.phone = l2.phone AND s1.pipeline_id = s2.pipeline_id нужно удалить из leads все с одинаковым phone и заджойненным pipeline_id из statuses, кроме самого первого из повторных

0) какой-то миск из JOIN-ов и перечисления таблиц через запятую во FROM... Как минимум, это нечитаемо, как максимум, СУБД не поймёт. 1) LEFT JOIN - неправильно использовать тут, потому что ты фильтруешь записи тут, потому что у тебя DELETE, а внешний JOIN НЕ ПОДРАЗУМЕВАЕТ фильтрацию. По факту у тебя JOIN ВСЁ РАВНО НЕ ВНЕШНИЙ, поскольку поля обеих таблиц участвуют в WHERE. Подозреваю, что логика запроса также может быть нарушена.

Ты бы указал на СУБД, у всех СУБД планы разные.

За был что тут про все СУБД канал. MS SQL

Поправь лучше начальное сообщение.

Что-то я туплю. Можно определение триггера вытащить как-то в постгресе? чтоб не ручками строить, а готовое? Ато гуглится только как процедуру достать,а она мне как раз нафиг не сдалась

или только руками пересобирать на основе information_schema.triggers?

information_schema.triggers - это не очень похоже на постгрес

Или там такая схема тож есть? Не припомню

https://www.postgresql.org/docs/9.5/static/information-schema.html

Дык может иньекцию просто попытались сделать?

Здравствуйте! Я с вопросом (MsSQL2017): The specified pattern did not return any files or does not represent a valid file share. Verify the pattern parameter and rerun the command. Сделал я аудит (в локальный файл, на одном сервере с СУБД), настроил, создал вьюху, делаю по ней клик и селект 1000 строк, а оно вот так в ответ ругается. На другой ДБ всё завелось сразу и влёт. Что смотреть\как дебажить? Селект вручную через execute отрабатывает корректно.

Здравствуйте! Я с вопросом (MsSQL2017): The specified pattern did not return any files or does not represent a valid file share. Verify the pattern parameter and rerun the command. Сделал я аудит (в локальный файл, на одном сервере с СУБД), настроил, создал вьюху, делаю по ней клик и селект 1000 строк, а оно вот так в ответ ругается. На другой ДБ всё завелось сразу и влёт. Что смотреть\как дебажить? Селект вручную через execute отрабатывает корректно.

Если совсем глубоко, то с помощью вот этой штуки docs.microsoft.com/en-us/sysinternals/downloads/procmon отследить обращения к файлам.

Если совсем глубоко, то с помощью вот этой штуки docs.microsoft.com/en-us/sysinternals/downloads/procmon отследить обращения к файлам.

Ох, не хотелось, но придётся, спасибо, пока что так начну искать проблему.

Ох, не хотелось, но придётся, спасибо, пока что так начну искать проблему.

Да понятно что слишком "тяжёлое" средство и вывод долго фильтровать придётся чтобы докопаться до первопричины.

Да понятно что слишком "тяжёлое" средство и вывод долго фильтровать придётся чтобы докопаться до первопричины.

Открыл. Посмотрел. Не нашёл обращений туда, куда искал. Переименовал вьюху и, на всякий случай, папку аудита. Всё завелось.

Всем привет. Парни, можно ли както в MySQL сделать одним запросом такую штуку: Есть форма для добавления книги, там есть поле "Автор", которое заполняется от руки и поля книги (title, description, ...) Авторы и книги хранятся в разных таблицах, связаны по id <-> user_id Надо при добавлении книги проверять наличие автора в таблице авторов и отдавать id и инсертить книгу - это решается insert from select... А если автора нет, то надо его добавить, получить id добавленного и потом с этим id инсертить книгу. Это в одном запросе реально или все-таки придется на несколько разбить?

Всем привет. Парни, можно ли както в MySQL сделать одним запросом такую штуку: Есть форма для добавления книги, там есть поле "Автор", которое заполняется от руки и поля книги (title, description, ...) Авторы и книги хранятся в разных таблицах, связаны по id <-> user_id Надо при добавлении книги проверять наличие автора в таблице авторов и отдавать id и инсертить книгу - это решается insert from select... А если автора нет, то надо его добавить, получить id добавленного и потом с этим id инсертить книгу. Это в одном запросе реально или все-таки придется на несколько разбить?

Можно сделать автора уникальным и всегда инсёртить, поставив на конфликт игнор/апдейт. Но я не уверен, что это хорошая идея..

Можно сделать автора уникальным и всегда инсёртить, поставив на конфликт игнор/апдейт. Но я не уверен, что это хорошая идея..

то есть, лучше все-таки разнести эту логику? и, например, сначала проверять наличие автора, а потом по условиям выполнять тот или иной код, верно?

а... если всегда инсёртить, может как-то через транзакции можно?

Ну ты по определению не сможешь сделать добавление в две таблицы одним запросос.

Но ты можешь сделать это одним обращением к базе если в нем сразу два запроса отправищь

Insert into t1 values(1,cat,15); Insert into t2 values(dogz, Igor, 27);

дружно идем читать, что такое транзакция

Всем привет. Парни, можно ли както в MySQL сделать одним запросом такую штуку: Есть форма для добавления книги, там есть поле "Автор", которое заполняется от руки и поля книги (title, description, ...) Авторы и книги хранятся в разных таблицах, связаны по id <-> user_id Надо при добавлении книги проверять наличие автора в таблице авторов и отдавать id и инсертить книгу - это решается insert from select... А если автора нет, то надо его добавить, получить id добавленного и потом с этим id инсертить книгу. Это в одном запросе реально или все-таки придется на несколько разбить?

Нет, это в одном запросе нереально сделать.

Всем привет. Парни, можно ли както в MySQL сделать одним запросом такую штуку: Есть форма для добавления книги, там есть поле "Автор", которое заполняется от руки и поля книги (title, description, ...) Авторы и книги хранятся в разных таблицах, связаны по id <-> user_id Надо при добавлении книги проверять наличие автора в таблице авторов и отдавать id и инсертить книгу - это решается insert from select... А если автора нет, то надо его добавить, получить id добавленного и потом с этим id инсертить книгу. Это в одном запросе реально или все-таки придется на несколько разбить?

Надо писать хранимую процедуру

дружно идем читать, что такое транзакция

Погоди, про транзакции до них пока не дошло...

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

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

Надо писать хранимую процедуру

О, а это вариант. А можно где подробнее почитать с примерами?

mysql.com

не знаешь такой сайт?

не знаешь такой сайт?

Два раза нажимал

майсиквел дат ком

майсиквел дат ком

Ох уж этот рязанский акцент :)

Ох уж этот рязанский акцент :)

май нейм ис саша, айм ливин раша

Йу спиик инглишь?

йес, а литл бит, ар ю?

https://www.youtube.com/watch?v=PZq01kQ5Pr8

есть табличка с 3 000 000 записей. запрос SELECT COUNT(DISTINCT lead_id) AS some_alias FROM lead_statistics WHERE is_actual in ('1', '2') and lead_statistics.created_at >= '2018-05-01 00:00:00' and lead_statistics.created_at <= '2018-05-12 00:00:00' выполняется 6 сек. как можно ускорить?

EXPLAIN смотреть надо

Селективность нормальная, может помочь индекс на created_at

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

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

лол, создал индекс на created_at. запрос выполнялся более 30 сек. на 30 остановил,чтобы сервак не лег)

Небось еще на проде выполнял, кто ж так делает

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

браво)

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

гениально

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

максимум 2 секунды)

Если преимущественно по дате фильтруете, то можно партиционировать по ней

всем привет, может кто подскажет. mysql во время рековери стартует еще процессы рековери и соответственно блочит себя же.. никто не сталкивался с таким ?

такое ощущение что по таймауту что ли отваливается

доходит примерно до 40% а потом опять лсн начинает считывать стартуя перед этим процесс

есть табличка с 3 000 000 записей. запрос SELECT COUNT(DISTINCT lead_id) AS some_alias FROM lead_statistics WHERE is_actual in ('1', '2') and lead_statistics.created_at >= '2018-05-01 00:00:00' and lead_statistics.created_at <= '2018-05-12 00:00:00' выполняется 6 сек. как можно ускорить?

Нормальное время...

есть табличка с 3 000 000 записей. запрос SELECT COUNT(DISTINCT lead_id) AS some_alias FROM lead_statistics WHERE is_actual in ('1', '2') and lead_statistics.created_at >= '2018-05-01 00:00:00' and lead_statistics.created_at <= '2018-05-12 00:00:00' выполняется 6 сек. как можно ускорить?

Индекс если есть по created at, и за этот диапазон мало записей, то должно все летать по индексу. Если много записей, индекс делать не нужно, и лучше уже не будет

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

всем привет, может кто подскажет. mysql во время рековери стартует еще процессы рековери и соответственно блочит себя же.. никто не сталкивался с таким ?

С чего ты взял, что он сам себя блокирует? Скорее всего, это просто recovery не срабатывает и падает, так что прощайся со своей Бд (если я прав конечно) гляди в логи

С чего ты взял, что он сам себя блокирует? Скорее всего, это просто recovery не срабатывает и падает, так что прощайся со своей Бд (если я прав конечно) гляди в логи

запустил майсклд в скрине с вербозе... все норм отрекаверил.. правда почему то поругался что нет директории var/run/mysqld , создал.. запустил уже скриптом и все норм

почему она удалилась хз

Добрый день. Хочу написать простенькое приложение под Андроид. Имеем ленту неких событий (изначально она одинаковая для всех пользователей), выводим их по одному от самых свежих к самым старым (DESC). Просмотренные скрываем навсегда только для конктреного пользователя, конечно. Если использовать старую добрую MySQL, то прихоидит в голову к таблице с событиями добавить таблицу со связями между id пользователя и id просмотренно записи. После чего выбирать нужные для показа записи запросом: SELECT t1.id, t1.values FROM t1 WHERE t2.user_id = xxx AND t1.id NOT IN (SELECT t2.id FROM t2) ORDER BY t1.id DESC LIMIT 1 Сомнения вызывает то, что 10 тыс пользователей, просмотрев по 10 тыс записей уже нагенерят 100 млн строк в t2... Будет ли это проблемой и на каком количестве? Можно ли как-то иначе все это реализовать, чтобы использовать NoSQL (Firebase от Гугла) или из-за отсутствия аналогов NOT IN и "!=" реляционная БД будет лучше?

Добрый день. Хочу написать простенькое приложение под Андроид. Имеем ленту неких событий (изначально она одинаковая для всех пользователей), выводим их по одному от самых свежих к самым старым (DESC). Просмотренные скрываем навсегда только для конктреного пользователя, конечно. Если использовать старую добрую MySQL, то прихоидит в голову к таблице с событиями добавить таблицу со связями между id пользователя и id просмотренно записи. После чего выбирать нужные для показа записи запросом: SELECT t1.id, t1.values FROM t1 WHERE t2.user_id = xxx AND t1.id NOT IN (SELECT t2.id FROM t2) ORDER BY t1.id DESC LIMIT 1 Сомнения вызывает то, что 10 тыс пользователей, просмотрев по 10 тыс записей уже нагенерят 100 млн строк в t2... Будет ли это проблемой и на каком количестве? Можно ли как-то иначе все это реализовать, чтобы использовать NoSQL (Firebase от Гугла) или из-за отсутствия аналогов NOT IN и "!=" реляционная БД будет лучше?

Нененене.

ХОчешь чтобы быстро работало — делай наоборот. Связь для пользователя с записями, КОТОРЫЕ ЕМУ НАДО БУДЕТ ПОКАЗАТЬ! При просмотре связь удаляется. При добавлении события она связывается со всеми пользователями, которые заинтересованы в ней

Добрый день. Хочу написать простенькое приложение под Андроид. Имеем ленту неких событий (изначально она одинаковая для всех пользователей), выводим их по одному от самых свежих к самым старым (DESC). Просмотренные скрываем навсегда только для конктреного пользователя, конечно. Если использовать старую добрую MySQL, то прихоидит в голову к таблице с событиями добавить таблицу со связями между id пользователя и id просмотренно записи. После чего выбирать нужные для показа записи запросом: SELECT t1.id, t1.values FROM t1 WHERE t2.user_id = xxx AND t1.id NOT IN (SELECT t2.id FROM t2) ORDER BY t1.id DESC LIMIT 1 Сомнения вызывает то, что 10 тыс пользователей, просмотрев по 10 тыс записей уже нагенерят 100 млн строк в t2... Будет ли это проблемой и на каком количестве? Можно ли как-то иначе все это реализовать, чтобы использовать NoSQL (Firebase от Гугла) или из-за отсутствия аналогов NOT IN и "!=" реляционная БД будет лучше?

NoSQL как всегда тут ни при чём вообще.

ХОчешь чтобы быстро работало — делай наоборот. Связь для пользователя с записями, КОТОРЫЕ ЕМУ НАДО БУДЕТ ПОКАЗАТЬ! При просмотре связь удаляется. При добавлении события она связывается со всеми пользователями, которые заинтересованы в ней

т.е. если у меня 100 тысяч пользователей, то мне при добавлении новой записи надо добавить 100 тысяч связей?

а при 15.000 записей и регистрации нового пользователя придется добавить 15.000 связей

т.е. если у меня 100 тысяч пользователей, то мне при добавлении новой записи надо добавить 100 тысяч связей?

можно хранить идентификатор последней просмотренной записи для каждого пользователя

можно хранить идентификатор последней просмотренной записи для каждого пользователя

плюсую

и общую ленту событий

только с мелким уточнением

юзверь же может смотреть не по порядку

можно хранить идентификатор последней просмотренной записи для каждого пользователя

если бы мы шли от 1 до 100.000, то это бы сработало :)) но мы идем от 100.000 к 1 и завтра может появиться 100.001

юзверь же может смотреть не по порядку

не может. мы задаем порядок

эээ, какие вы злые

но он не должен увидеть одну запись дважды

если бы мы шли от 1 до 100.000, то это бы сработало :)) но мы идем от 100.000 к 1 и завтра может появиться 100.001

А что мешает в очереди такой убогой сделать ещё один идентификатор порядка?

типа один раз проскролил и всё?)

"Эта запись скрыта от тебя НАВСЕГДА.. потому что ты ее уже видел" ?

типа один раз проскролил и всё?)

да... типа как в RSS - посмотрел и все

вообще печаль

если бы мы шли от 1 до 100.000, то это бы сработало :)) но мы идем от 100.000 к 1 и завтра может появиться 100.001

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

А что мешает в очереди такой убогой сделать ещё один идентификатор порядка?

как это работает?

типа один раз проскролил и всё?)

Угу. И потом уже даже не вернешься и не перечитаешь. Потому что НАВСЕГДА