Если и так, то какое отношение к этому имеют разрабы? Разрабы сидят на зарплате, у них есть четкие сроки. Свои косяки, пожалуйста, исправляйте во внеурочное время. Почему компания должна их ошибки.

это чат для нытья?

только для нытья по базам

что можно сделать? SELECT ORDERS.* FROM ORDERS LEFT OUTER JOIN ORDERSTRANSLOG ON ORDERS.ID_NUM = ORDERSTRANSLOG.ID_NUM WHERE ORDERSTRANSLOG.TRANSFERED is null ну кроме того, чтобы гвоздь в голову вбить тому, кто такое придумал

а что смущает то? нормальная вещь

хотя наверно where смущает

тут уже логику надо понимать

берет сначала все строки из orders, джойнит к ним log. и там где лог не приджонился (нет его) - только те строчки выводим.

а строчек в orders - дохреналлиард

код приложения менять не могу (

но текст запроса - могу

берет сначала все строки из orders, джойнит к ним log. и там где лог не приджонился (нет его) - только те строчки выводим.

ну вообще-то не так

я хз что там с ddl, но на первый взгляд логика не такая

а по orders никакого селективного условия нет?

зачем весь охулиард брать

с квери да, проблем никаких нет, обычная проверка на exists

а по orders никакого селективного условия нет?

в том то и дело. ни даты, нихрена.

потому и ною

Груздь

ныть надо по поводу того, что на null проверяется не id связи

думаешь даст прирост?

поэтому логика "и там где лог не приджонился" априори не работает, если id есть, а TRANSFERED null

ну да, это не совсем очевидено, вариант с id понадежнее будет

опять же, не зная ddl

да даже если там is not null поле, все равно так не стоит писать

да не. в orderstranslog либо вообще нет строчек, либо поле transfered уже заполнено (и они нам не нужны)

в логе же тоже охулиард?

угу

1-к-1

Партиционировать ORDERS и потом выбирать из партиции, если oracle.

sql2k8 ладно. truncate - выход

1-к-1

если 1:1, то зачем вообще лефтджоин?

Суть же выбора у которых нет соответствия

Партиционировать ORDERS и потом выбирать из партиции, если oracle.

и смысл?

Товарищи, что бы вы выбрали в качестве базы данных для месенджера?

Чисто ваше имхо

Зависит от требований. В самых простых случаях можно вообще в файл писать

Ну про файл ты загнул. Допустим будет хайлоад и миллионы пользователей.

#каквыбратьбазуданных 1. Точные требования с рассчетом на будущее 2. Что умеем лучше готовить

и смысл?

Странный вопрос. Смысл в том чтобы не лопатить всю таблицу, а только партицию. Если смысла нет, то не пользуйтесь)

Ну про файл ты загнул. Допустим будет хайлоад и миллионы пользователей.

Я же написал "зависит от требований"

Ну про файл ты загнул. Допустим будет хайлоад и миллионы пользователей.

у кого хайлоад и миллионы пользователей и так знают

и это не требование

Странный вопрос. Смысл в том чтобы не лопатить всю таблицу, а только партицию. Если смысла нет, то не пользуйтесь)

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

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

В качестве примера можно взять телегу

Ок, ясно

Что стало ясно, если не секрет?

Вопрос из серии, какой яп выбрать для телеги

но текст запроса - могу

Ну, напиши через NOT EXISTS, но обычно все СУБД понимают такую хрень правильно и нормально оптимизируют.

берет сначала все строки из orders, джойнит к ним log. и там где лог не приджонился (нет его) - только те строчки выводим.

Это неправда. При выполнении запроса нет СНАЧАЛА и ПОТОМ.

Товарищи, что бы вы выбрали в качестве базы данных для месенджера?

Зачем мессенджеру база данных?

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

Бери чисто сферическую СУБД в вакууме тогда, точно не ошибёшься!

Ну, напиши через NOT EXISTS, но обычно все СУБД понимают такую хрень правильно и нормально оптимизируют.

чего? не понял

вот так могу select * from ORDERS where id_num not in (select id_num from ORDERSTRANSLOG) но существенного прироста нет

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

пфф..оптимизатор вероятней всего переписал ваш запрос на тот же join

Вообще вопрос с запросом почему встал? Медленное выполнение, большая нагрузка?

Вообще вопрос с запросом почему встал? Медленное выполнение, большая нагрузка?

и то и другое

План выполнения запроса какой?

походу единственным решением (ну кроме и правда транкейта, который не исключен) будет дополнение новым полем вроде "ignore", с проставлением в него галочек периодическим заданием. ну и добавлением условия в исходный запрос.

Если поднимает все данные с диска. То как было уже предложено можно спастить партиционированием. Естественно, если соотношений существующих и отсутствующих записей удовлетворительное.

пфф..оптимизатор вероятней всего переписал ваш запрос на тот же join

планы разные

План выполнения запроса какой?

какого именно запроса?

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

Можно и так, но не обязательно будет прирост производительности. И ты не прав, что предполагаешь как-то, что запрос будет выполняться по какой то логике "СНАЧАЛА-ПОТОМ". Надо в план запроса смотреть, как он выполняется.

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

Реляционное вычитание — да, одна из самых сложных операций РСУБД, что же ты хотел-то?

что можно сделать? SELECT ORDERS.* FROM ORDERS LEFT OUTER JOIN ORDERSTRANSLOG ON ORDERS.ID_NUM = ORDERSTRANSLOG.ID_NUM WHERE ORDERSTRANSLOG.TRANSFERED is null ну кроме того, чтобы гвоздь в голову вбить тому, кто такое придумал

вот что я хотел )