Цитата:
Сообщение от
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 уж не обижайтесь - я не про Вас, ваши обиды мне дорого обходятся...
