powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Прошу помощи с JOIN
19 сообщений из 44, страница 2 из 2
Прошу помощи с JOIN
    #40104326
Rom1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всё решил с помощью временной таблицы, в неё отгружаю (update or insert) записи из USAGE N -> GOODSID, sum(AMOUNT) as SUM N
В результате получаю время выполнения 2 минуты, против 40-60 встроенными селектами.

Ну так как таблица временная, то во время запуска процедуры она будет очищаться, потом заполняться (как описал выше), а это даст хреновую статистику по апдейтам. Что с этим делать, пока не знаю.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104401
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Rom1,

Как 2 минуты? У Вас миллионы (десятки, сотни) записей?
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104408
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXI
Rom1,

Как 2 минуты? У Вас миллионы (десятки, сотни) записей?


Дык. Таблицу-то временную ещё ж залить надо. Я бы сделал селективную процедуру с тремя запросами раз уж очень хочется одним клиентским запросом и не парился.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104440
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишка,

у ТС запрос выполняется 40-60 минут. Что там?
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104478
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXI
Старый плюшевый мишка,

у ТС запрос выполняется 40-60 минут. Что там?


Хрень какая-то, а какая сказать трудно, он толком ничего не говорит, а что говорит, говорит с ашипками. Но три иннера по-любому уделают этажерку с юнионами. Если с индексами всё боле-мене ;)
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104617
Rom1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
KreatorXXI
Как 2 минуты? У Вас миллионы (десятки, сотни) записей?

USAGE N , это не плоские таблицы, там несколько выборок с агрегацией и кучей джойнов, около 3 млн записей на всё.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104629
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Rom1
Всё решил с помощью временной таблицы, в неё отгружаю (update or insert) записи из USAGE N -> GOODSID, sum(AMOUNT) as SUM N
В результате получаю время выполнения 2 минуты, против 40-60 встроенными селектами.

Ну так как таблица временная, то во время запуска процедуры она будет очищаться, потом заполняться (как описал выше), а это даст хреновую статистику по апдейтам. Что с этим делать, пока не знаю.

Зачем update or insert, почему-бы не обойтись только insert?
Зачем очищать таблицу во время запуска процедуры? (ну разве что в одной транзакции несколько раз будешь её запускать, да и то можно без очистки обойтись)
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104701
Rom1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
m7m
Зачем update or insert, почему-бы не обойтись только insert?
Зачем очищать таблицу во время запуска процедуры? (ну разве что в одной транзакции несколько раз будешь её запускать, да и то можно без очистки обойтись)

Так товар может и не присутствовать в USAGE 1 , там в SUM1 будет 0. А допустим будет только в USAGE 3 , там в SUM3 будет будет некая сумма всех значений этого товара в выборке.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104704
Rom1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Наверное не так ответил на ваш вопрос. Перефразирую - во временной таблице через (uppdate or insert) я получаю всего одну запись, в которой будут заполнены все SUM N по GOODSID, а может и не все, но всё равно это будет всего одна запись. А если использовать только инсерты, то я получу по каждому GOODSID от 0 до N SUM's и всё это придется еще агрегировать.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104711
Rom1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Еще добавлю. Очистка производится один раз, для получения сводных данных по товару, это срез данных на текущий момент, в следующий раз эти данные будут уже не актуальны и всё придется делать с чистого листа. Поэтому это и временная таблица, только для формирования остатков по всем USAGE N
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104717
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почему бы не формировать остатки в реальном времени? Тогда запрос будет
выполняться за доли секунды.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104720
Rom1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov

Почему бы не формировать остатки в реальном времени? Тогда запрос будет
выполняться за доли секунды.

В реальном времени можно это делать по одной единице товара, да и это займет времени совсем чуть, можно даже кешировать результат. Однако мне нужен срез по пулу товаров, и тут всё работало, но не устраивало время выполнения этой операции, потому что перебиралась "руками" каждая единица товара из пула. Это просто вопрос оптимизации.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104723
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Эта оптимизация уже давно называется "OLAP" и делается без особых проблем как
руками, так и готовыми инструментами. Ничто же не мешает строить куб по твоему
"пулу"...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104785
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В любом случае 3 млн записей за 2 минуты (не говоря о 40-60) - это непозволительно много. Надо оптимизировать или пересматривать запросы совсем. Было бы 3 млрд, можно было бы и о кубах подумать.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104791
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Rom1
Dimitry Sibiryakov

Почему бы не формировать остатки в реальном времени? Тогда запрос будет
выполняться за доли секунды.

В реальном времени можно это делать по одной единице товара, да и это займет времени совсем чуть, можно даже кешировать результат. Однако мне нужен срез по пулу товаров, и тут всё работало, но не устраивало время выполнения этой операции, потому что перебиралась "руками" каждая единица товара из пула. Это просто вопрос оптимизации.



Мнэээ... Этот срез нужен с точностью до миллисекунды? Помнится, была у меня в обиходе табличка для стратегической и тактической аналитики. Ну там ABC, теория управляемого накопителя, бюджетирование и всё такое. По трём линиям поставки - Европа, Азия и остальной мир, с комплектационными складами на линиях, товарах на них, в пути между ними, в пути от поставщиков, в принятых к исполнению поставщиками заказах, в отправленных поставщикам на утверждение (даты они ещё могли поменять), доходностями, наличием денег в определённых банках, прогнозами их прибытия на основе статистики прошлых лет и тенденций момента, первой и второй производными приходов и расходов и прогнозами состояния запасов в перечисленных стадиях на месяц, два... полгода, ещё чего-то, не помню уже, короче к сотне полей. На фоне сотни тыщ позиций номенклатуры. Пересчитывалась инсёртами с датой (чтобы можно было сравнить свои представления с любым временным интервалом) по ночам часа за три. На серваке сборки 2004 года и FB 1.5. Ну кого в течение дня мнэээ... колыхало, что за день картина ушла на полпроцента? На крайняк для отражения кардинальных судьбоносных изменений по группе товаров был предусмотрен оперативный пересчёт по именно ней. Кеширование, ля...

Ещё вопрос имею, чиста для самообразования. Чем временная таблица в срочно-оперативной схеме интересней возврата агрегированных данных в параметрах процедуры, которая их наагрегировала, не беспокоя диск?
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104792
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXI
В любом случае 3 млн записей за 2 минуты (не говоря о 40-60) - это непозволительно много. Надо оптимизировать или пересматривать запросы совсем. Было бы 3 млрд, можно было бы и о кубах подумать.


9 млн за 40 секунд в 2004 году.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40104887
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Rom1
m7m
Зачем update or insert, почему-бы не обойтись только insert?
Зачем очищать таблицу во время запуска процедуры? (ну разве что в одной транзакции несколько раз будешь её запускать, да и то можно без очистки обойтись)

Так товар может и не присутствовать в USAGE 1 , там в SUM1 будет 0. А допустим будет только в USAGE 3 , там в SUM3 будет будет некая сумма всех значений этого товара в выборке.

Rom1
Наверное не так ответил на ваш вопрос. Перефразирую - во временной таблице через (uppdate or insert) я получаю всего одну запись, в которой будут заполнены все SUM N по GOODSID, а может и не все, но всё равно это будет всего одна запись. А если использовать только инсерты, то я получу по каждому GOODSID от 0 до N SUM's и всё это придется еще агрегировать.

Ну так и суммируй их, возможно это лучше чем апдейтить и может быть даже гораздо лучше
Rom1
Еще добавлю. Очистка производится один раз, для получения сводных данных по товару, это срез данных на текущий момент, в следующий раз эти данные будут уже не актуальны и всё придется делать с чистого листа. Поэтому это и временная таблица, только для формирования остатков по всем USAGE N
Зачем временную таблицу чистить
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40108548
Rom1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Задача решена, выполняется быстро. Однако во время перевода в продакт, занимались чисткой лишних индексов и был удален обязательный индекс по GOODSID, во временной таблице. После этого время выполнения снова подскочило до ~1 часа.

Отсюда я могу предположить, что вариант, как с временной таблицей, так и с вложенными запросами - одинаково производительны. НО! При вложенном запросах, видимо, необходимо грамотно составлять план, чтобы построились временные индексы. Но я в планах не силён, от слова совсем, поэтому мой вариант - временная таблица.

Пишу это потому, что некоторые участники заинтересовались почему может быть такая разница в производительности.
...
Рейтинг: 0 / 0
Прошу помощи с JOIN
    #40108556
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Rom1
При вложенном запросах, видимо, необходимо грамотно составлять план, чтобы построились временные индексы. Но я в планах не силён, от слова совсем, поэтому мой вариант - временная таблица.

Какие такие временные индексы? А планами занимается встроенный планировщик. В Вашем примере достаточно всё просто. Придумали себе проблему.
...
Рейтинг: 0 / 0
19 сообщений из 44, страница 2 из 2
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Прошу помощи с JOIN
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]