InventLocationId в InventTrans

[Мартынов Дмитрий]

Цитата:

Сообщение от fed

А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на пацанском научном C++, потому что все нормальные пацаны ученые пишут только на C++, который компилируется не в ламерский байткод, а в настоящие процессорные команды. Что, конечно же, очень увеличивает степень подобия такого теста исполнению join внутри SQL Server...

Интересно, что когда я не вдаюсь в технические детали - то меня начинаю обвинять в невежестве... Разница между B-деревом и сортированной таблицей с точки зрения нашей задачи небольшая. Более того если мы создаем правильные структуры данных и делаем правильные запросы, то разница между ними вообще не в пользу B-дерева.

Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3.

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

[fed]

Цитата:

Сообщение от Мартынов Дмитрий

Интересно, что когда я не вдаюсь в технические детали - то меня начинаю обвинять в невежестве... Разница между B-деревом и сортированной таблицей с точки зрения нашей задачи небольшая. Более того если мы создаем правильные структуры данных и делаем правильные запросы, то разница между ними вообще не в пользу B-дерева.

No comments. Если делаем правильные структуры, можно жить на голых таблицах - без B-Tree. Вероятно будет пересортировывать после каждой вставки и обновления. Очевидно это тот самый "научный подход" в действии.

Цитата:

Сообщение от Мартынов Дмитрий

Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3.

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

Цитата:

Сообщение от Мартынов Дмитрий

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

Не хочешь чтобы над тобою стебались, почитай для начала Вирта "Алгоритмы и структуры данных (про B-Деревья и Хэш-таблицы) и почитай в BOL про виды джойнов в SQL Server. Еще можно почитать блог Craig Freeman Так что знания не тайные, просто, вероятно, твой ''научный подход" - это такое политически корректный термин для "невежество".

[Мартынов Дмитрий]

Цитата:

Сообщение от fed

No comments. Если делаем правильные структуры, можно жить на голых таблицах - без B-Tree. Вероятно будет пересортировывать после каждой вставки и обновления. Очевидно это тот самый "научный подход" в действии.

Если мы не имеем аппаратных средств копирования блоков памяти, то при качественном проектировании БД В-дерево проиграет классическому индексу. Кстати и в обратную сторону - если у нас есть аппаратные средства сортировки то опять же сортировка выиграет. Но технически копирования блоков памяти фиксированного размера в железе реализуется проще, по этому все перешли на В-трее...

Цитата:

Сообщение от fed

Не хочешь чтобы над тобою стебались, почитай для начала Вирта "Алгоритмы и структуры данных (про B-Деревья и Хэш-таблицы) и почитай в BOL про виды джойнов в SQL Server. Еще можно почитать блог Craig Freeman Так что знания не тайные, просто, вероятно, твой ''научный подход" - это такое политически корректный термин для "невежество".

За Вирта спасибо, вообщето начать надо с Тьюринга и Черча... сижу изучаю....Дейкстру почитываю... Кстати, из наших рекомендую прежде всего Ершова.

[S.Kuskov]

Цитата:

Сообщение от Мартынов Дмитрий

Если мы не имеем аппаратных средств копирования блоков памяти, то при качественном проектировании БД В-дерево проиграет классическому индексу.

Что вы называете "классическим индексом"?

[Мартынов Дмитрий]

Цитата:

Сообщение от S.Kuskov

Что вы называете "классическим индексом"?

В данном случае я имел ввиду индекс, который храниться как отсортированная таблица.

[AndyD]

Цитата:

Сообщение от Мартынов Дмитрий

В данном случае я имел ввиду индекс, который храниться как отсортированная таблица.

Прошу прощения, а что имеет в виду под "Отсортированной таблицей"?
И как в этой таблице искать?

[S.Kuskov]

Цитата:

Сообщение от AndyD

Прошу прощения, а что имеет в виду под "Отсортированной таблицей"?
И как в этой таблице искать?

Уточню вопрос. Чем поиск по отсортированной таблице отличается от поиска по неотсортированной?

[Vadik]

Цитата:

Сообщение от Мартынов Дмитрий

Если мы не имеем аппаратных средств копирования блоков памяти, то при качественном проектировании БД В-дерево проиграет классическому индексу. Кстати и в обратную сторону - если у нас есть аппаратные средства сортировки то опять же сортировка выиграет
..
Зависит конечно, но по сути не зависит

Дмитрий, есть предложение вернуться к решению задачи поставленной в начале ветки (напомню - ускорение оборотки по складу за счет добавления InventLocationId в InventTrans) на основе коммерчески доступных в данное время в данной галактике технологий (AX, X++, SQL Server \ Oracle). Если по существу добавить нечего - пожалуйста, воздержитесь от увода ветки в оффтопик

[Pustik]

Коллеги, добрый вечер.
Был занят, поэтому не мог принимать участие в дискуссии..Многие моменты, о чем здесь говорилось, заинтересовали.
Началось все с того, что на протяжении многих лет, оборотка(и другие отчеты, написанные в 2003-4 году) стали немного напрягать по времени выполнения. Да они выполняются 3-6 минут, но это все равно как-то долговато. Особенно, если тебе звонит бухгалтер и говорит, что у него не идет что-то с обороткой ( ждать немного раздражает ). Сразу скажу, что у нас построение оборотки основаано на inventSum. Естественно, все оборотки чаще всего смотрятся в разрезе склада.
Тест происходил следующим образом : Запустил оборотку c InventDim, замерил время выполнения всех запросов в алгоритме (время вывода на экран не в счет) - 3 мин. Далее перенес склад в InventTrans, как указал выше. Единственное, что забыл сказать - я проиндексировал склад. Запустил. Время выполнения 20 сек.На этом мое тестирование закончилось. Я вынес предввыводы для себя и захотел услышать мнение других людей.
После того, как я полностью прочитал ветку, засомневался, и сегодня протестировал это более тщательно.А именно, после запуска оборотки, которая использует inventLocationid в inventtrans, я снова запустил оборотку старого образца. Увидел, что она стала выполняться за 32 секунды. Т.е. первый раз за 3 мин. - второй(с перенесенным складом) за 20 секунд - и третий раз(снова по первому варианту) за 32 секунды. Тут у меня возник интерес к фразе fed-а об оптимизации запросов. Честно признаюсь, что я представляю, что такое оптимизация и статистика запросов, но лично с этим не дружил .
Сравнивать с рабочей базой думаю смысла нет. Там совершенно другие параметры SQL и AOS-а.Переносить склад в inventTrans пока не планируем (боимся)
Да, добавлю, что для тестирования использовал не очень "частый" склад.

[gl00mie]

Цитата:

Сообщение от Pustik

я снова запустил оборотку старого образца. Увидел, что она стала выполняться за 32 секунды. Т.е. первый раз за 3 мин. - второй(с перенесенным складом) за 20 секунд - и третий раз(снова по первому варианту) за 32 секунды.

Это еще отчасти может об'ясняться тем, что после первого прогона оборотки СУБД закэшировала все необходимые данные и перестала начитывать их с диска.

[Alexius]

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

[Мартынов Дмитрий]

Цитата:

Сообщение от Vadik

Дмитрий, есть предложение вернуться к решению задачи поставленной в начале ветки (напомню - ускорение оборотки по складу за счет добавления InventLocationId в InventTrans) на основе коммерчески доступных в данное время в данной галактике технологий (AX, X++, SQL Server \ Oracle). Если по существу добавить нечего - пожалуйста, воздержитесь от увода ветки в оффтопик

В соответствии с п.3.12 вынужден подчиниться......

Цитата:

Сообщение от S.Kuskov

А вы учитываете, что дерево балансируется относительно значений хранящихся в таблице, а ваш "класический индекс" относительно их размера/местоположения? Т.е. вы допускаете, что величины в вашем биллионе записей могут быть распределены неравномерно?

Вынужден оставить без ответа... Не вижу здесь офтопика (даже берусь доказать обратное) но не смею спорить с модератором...