На прошлых выходных развлекался попытками разогнать (в смысле, ускорить) стандартную процедуру на MS SQL (путем изнасилования кода процедуры). Заодно прочитал сначала данную ветку. Очень интересно.
Цитата:
Сообщение от
Yaroslav Batozskiy
...
Наш скрипт написан целиком на T-SQL
...
А стандартная процедура пересчета RecId не далека от этого состояния.
Цитата:
Сообщение от
Yaroslav Batozskiy
...
поэтому работает быстро (2 ГБ базы пересчитывается меньше, чем за полчаса на четырехпроцессорном XEON).
...
В моем случае на базе в 5 Gb с хвостиком (правда данных всего 2.5 Gb и столько же под индексами) удалось выйти на результат около 1:40. На однопроцессорном лаптопе (правда, база и лог были на внешнем диске: один, обычный IDEшный, подключенный по USB-интерфейсу). Память под MS SQL Server была ограничена до 300 Mb. Т.о. цифра далеко не предельная. В ходе опыта явно видно, что для дальнейшего ускорения процедуры нужно наращивать дисковую подсистему и/или память SQL Server.
Так что в плане скорости вышеупомянутый скрипт, IMHO, не является панацеей.
Цитата:
Сообщение от
Yaroslav Batozskiy
...
Ув. glibs. Я просто дал совет. Хотите-разберитесь, хотите-проигнорируйте.
...
Поглядев на код и поэкспериментировав неприязнь к штатному алгоритму не разделяю. Скорее наоборот я бы отдал предпочтение стандартному алгоритму, нежели алгоритму, который не использует данные из АОТа и работает исключительно на базе эвристического анализа с элементами теории вероятности.
Хотя использовать его для обнаружения незадокументированных должным образом в АОТе связей по RecId можно попробовать. А много вышеупомянутый скрипт нашел таких связей (если вдруг Yaroslav Batozskiy не ответит на данный вопрос, может кто-то имел возможность скриптом попользоваться на законных основаниях и может прокомментировать)?