Как сравнивать реализации?
Вообще-то для сравнения разных реализаций на однотипной рабочей нагрузке принято использовать эталонные тестовые наборы (benchmark). Наиболее авторитетной организацией, поставляющей такие тестовые наборы, является Transaction Processing Performance Council (TPC). В типичную спецификацию тестового набора входит структура и содержимое тестовой базы данных и правила построения тестовых приложений. Все ведущие производители СУБД регулярно производят испытания своих продуктов на основе разных тестовых наборов TPC и публикуют свои результаты.
К сожалению, существуют достаточно жесткие ограничения относительно сравнительных испытаний на одном и том же тестовом наборе и одной и той же аппаратуре своей СУБД и какой-либо системы другого производителя (обычно открытая публикация результатов таких испытаний запрещается под угрозой судебного преследования). Но эти ограничения можно обойти (как это делается, например, в [2]), если аккуратно сохранять анонимность системы, с которой производится сравнение.
Итак, количественное и даже качественное сравнение двух реализаций СУБД можно производить только на одной и той же рабочей нагрузке (в случае количественного сравнения требуется использовать одну и ту же базовую аппаратно-программную платформу). Обычно эталонный тестовый набор специфицируется в терминах некоторой модели данных (как правило, SQL). Если требуется применить его к системе, реализующей некоторую другую модель, необходимо аккуратнейшим образом реализовать эту спецификацию в терминах своей модели данных (или реализации, если модель, как таковая отсутствует). И даже после этого в сравнении с использованием такого "неканонического" тестового набора будет каким-то образом отражаться специфика его представления в другой модели данных.
Если сравнение двух реализаций (количественное или качественное) выполняется не в чисто маркетинговых целях, а для получения исследовательских экспериментальных результатов, то совершенно необходимо хорошо знать (настолько, насколько это возможно) особенности сравниваемой чужой реализации.
Иначе можно допустить неправильные рассуждения при качественном сравнении или неправильно проинтерпретировать результаты количественного сравнения.
Например, в статье А.Е. Васильева неверно представляется, что в реализациях модели данных SQL в листовых вершинах индексных В+-деревьев хранятся идентификаторы записей данных, при использовании которых для доступа к записям требуется дополнительный двоичный поиск в самих таблицах. Это не так. Идентификатор строки, хранящийся в индексной структуре, представляет собой "почти" прямой физический адрес в дисковой памяти, и никакого дополнительного поиска после нахождения идентификатора не требуется.
Более того, в некоторых реализациях (например, в Oracle) допускается очень быстрый доступ на уровне языка SQL к строкам таблиц по их "почти" физическим идентификаторам (rowid). И, конечно, если сравнивать реализацию Oracle с реализацией какой-либо "многомерной" СУБД, эту особенность скрытой от пользователей явной навигации нужно иметь в виду.
Кстати, SQL поддерживается и во многих СУБД, которые изначально разрабатывались как явно навигационные (например, в IMS, IDMS, той же Cache). С одной стороны, можно считать, что и эти системы являются реализациями модели данных SQL, но, с другой стороны, это совсем не такие реализации, как у систем, изначально разрабатывавшихся как SQL-ориентированные. И эти реализационные особенности систем тоже неоходимо иметь в виду при каких-либо сравнениях с их участием.
