Всем привет.

Есть две таблицы:

product
type_product, seller, сity
1,Иванов,Москва
2,Иванов,Екатеринбург
3,Петров,Москва

shopping
type_product, code_sale, date_sale
1, 111, 07.11.2013

Таблица shopping на 50% меньше таблицы product.

Мне необходимо, отобрать продажи Иванова, за сегодня, в Москве:

Select s.type_product, s.code_sale
from shopping s 
inner join product p on p.type_product = s.type_product and p.seller = 'Иванов' and p.city = 'Москва'
where s.date_sale >= current_date and s.date_sale < current_date + interval '1 day'

Вот я думаю... А что если перенести поле date_sale - в таблицу product ?
Подскажите, пожалуйста, такой запрос будет работать быстрее (с учетом того, что таблица product больше) :

Select s.type_product, s.code_sale
from product p 
inner join shopping s on p.type_product = s.type_product 
where p.date_sale >= current_date and p.date_sale < current_date + interval '1 day'
         and p.seller = 'Иванов' and p.city = 'Москва'

Спасибо :)

_____________

Что ты сделал сегодня - для завтра?
"Приидите ко Мне вси труждающиеся и обремененнии и Аз упокою вы, возмите иго Мое на себе и научитеся от Мене яко кроток есмь и смирен сердцем и обрящете покой душам вашим, иго бо Мое благо и бремя Мое легко есть."(Мф. 11:28-30)

code_sale что за поле? Мне кажется таблиц должно быть больше, ну 4-5.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

code_sale - дата продажи

_____________

Что ты сделал сегодня - для завтра?
"Приидите ко Мне вси труждающиеся и обремененнии и Аз упокою вы, возмите иго Мое на себе и научитеся от Мене яко кроток есмь и смирен сердцем и обрящете покой душам вашим, иго бо Мое благо и бремя Мое легко есть."(Мф. 11:28-30)

а тогда date_sale?

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

ABC
ой) ошиблась) code_sale - какой то параметр продажи) К сути во проса не относиться)

_____________

Что ты сделал сегодня - для завтра?
"Приидите ко Мне вси труждающиеся и обремененнии и Аз упокою вы, возмите иго Мое на себе и научитеся от Мене яко кроток есмь и смирен сердцем и обрящете покой душам вашим, иго бо Мое благо и бремя Мое легко есть."(Мф. 11:28-30)

Обычно делают по второму варианту. Измерить скорость и эффективность запроса можно в самой СУБД.

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

Есть что оптимизировать

join shopping s on p.type_product = s.type_product 

идентичные идентификаторы связей позволяют юзать using()

... join shopping using(type_product)

И по дате. Если одно и то же поле сравнивается с диапазоном, то юзают

between

1) Если <= 100 000 записей, то всё равно как - разница будет в тысячные секунды.
Если больше 1 000 000, то второй.
2) С учётом, что у Вас денормализованная БД...
После того, как перенесёте date_sale, подумайте хорошенько - нужна ли Вам таблица shopping, или от неё можно избавиться (соответсвенно и от join на неё).
3) Не забудьте добавить индекс "date_sale,selller"
4) Если Вам нужно именно "за сегодня", то диапазон не обязателен - достаточно "p.date_sale = curdate()". В т.ч. это эффективнее.
5) Не используйте "using", если недостаточно хорошо понимаете что это и как работает.
6) "between" не обязательно использовать - он просто красивше, а работает также как два сравнения.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

S.Chushkin

Ага, метод известный. Типа идите прочитайте, мне расскажите, мне все объясните, а я уж там и оценку дам - правильно или нет.

Короче, никакой опасности в using() нет. Более того, нормальный, типовой JOIN можно сразу назвать t1 NATURAL JOIN t2 и юзинг уже не юзать.

Самая же мякотка в том что пользуясь типовыми методами отбора данных у результа, скажем через fetch_assoc() вы все равно не получите ДВА поля с одинаковым именем. Только одно, какое-то. using() же это сделает из двух одно правильно.

Нашел в финальных титрах в чем нестандарт:

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

Вы же видели таблицы начинающих. Почему у них индивидуальные поля называются одинаково, а связанные поля - по-разному. Скажем в таблице продуктов есть поле name и в таблице категорий есть поле name, а бинды названы parent_id и id соответственно. Соединив такую байду получить два name можно только через MYSQLI_BOTH или как он там, флаг скачивания нумеречно-ассоциативного массива. Чисто "нумеречный" вообще никто не поднимает - тямы не хватает.

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

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

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

Это, блин, оффтоп, но это, блин, наша национальная болезнь. Намекать друг другу какие мы не%$#но умные, всей планеты впереди. Прямым текстом сказать - иди дурак, учись - нельзя. Выкинут за борт.