А как быть в таком случае?



Менеджеру необходимо сформировать заявку на основной склад.
Для этого необходимо получить список долгов его клиентам: DebtQty = BookingQty - ReserveQty - IssueQty

Получается, если не дублировать данные в другой таблице, то выходит такой запрос:


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

С ходу я вижу, что тут надо добавить столбец Status = TINYINT(1) unsigned, который будет содержать 1, если нет долгов и 0, если есть...
Тогда не придётся просчитывать DebtQty...

Как вариант, не добавлять столбец Status, а сделать столбец DebtQty, в который будет записываться количество долга.
Но в этом случае, надо будет при изменении количества заказа (или резерва) изменять ещё и количество долга.

К тому же, меня смущает то, что мне надо делать LEFT JOIN на таблицу `client`, чтобы узнать, относится ли этот клиент к этому менеджеру.
А если менеджеров будет тысяч 5-10 и клиентов на каждого менеджера тоже тысяч по 5-10?

----------------------------------------------------------------

Попутно возник ещё вопрос...

1. Мне надо отобразить список долгов, сгруппированных по артикулу, чтобы оформить заявку на основной склад.
2. Но мне так же надо получить BookingCommodityId и DebtQty, чтобы выставить на резерв товары, которые есть на складе.

Получается такой запрос...
Постарался в SQL-комментариях расписать, что да как...



Имеет ли смысл делать два конкретных запроса?
Или можно обойтись одним, просто группируя в PHP-скрипте по артикулу?

Это сообщение отредактировал(а) fridkaratel - 29.11.2012, 05:52

Если вы не будете пробовать получить все пару сотен тысяч записей сразу, то разницы с JOIN и без него вы не заметите.
В базах данных логарифмические алгоритмы посика. Видели график логарифма? Вот, увеличиваете количество на очень-очень много, а время увеличивается на чуть-чуть. И сортировка тоже логарифмическая. Невозможно сделать логарифмической только выборку. Так как N штук меньше чем за N действий не выберешь.

У вас на пинг между серверами времени больше будет тратится, чем у БД на обработку запросов. Посмотрите на этот форум: [ Время генерации скрипта: 0.3409 ]. А страница появляется далеко не моментально из-за пинга и загрузки информации.

Если вас беспокоит, придется ли менеджеру ждать несколько секунд после нажатия на кнопочку - БД тут точно будет ни при чем.
Если вас беспокоит, не упадет ли БД от множества неэффективных запросов - даже средний домашний компьютер вытянул бы 1тыс. INSERT'ов в секунду, в SELECT'ов и того больше.
Посчитайте: если 15000 менеджеров будут каждые 15 минут оформлять заказ и выполнять при этом по 10 запросов, то это выйдет в среднем 160 запросов в секунду. Если не считать утрированности этой ситуации, то это вообще очень мало.



Далеко не все должно иметь вид лога =) Можно изменять и уже имеющиеся записи. Впрочем да, если надо к каждому изменению комментарий, то надо отдельную таблицу для этого.


Вот и спрашиваю, почему вы все в один запрос пытаетесь вместить...
Посмотрите на это форум: [ Использовано запросов: 35 ], 223 гостей, 15 пользователей. И сервер же не падает.

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

Это сообщение отредактировал(а) Arantir - 29.11.2012, 08:26

@Arantir, спасибо за развёрнутый ответ ;)

Буду делать