Здравствуйте, _DeKa_, Вы писали:
_DK>Собственно говоря, это уже сейчас сделано и нормально работает на тестах. Т.е. все дескрипторы нормально помещаются в память и скорость линейного сравнения, в принципе, устраивает. _DK>Просто у каждого объекта есть еще информация, которая очень хорошо ложится в реляционную структуру. Поэтому и возникла идея все хранить в БД вместе с дескрипторами. Т.е. вопрос в следующем: можно ли организовать такой же линейный поиск, если данные лежат именно в таблице БД? И что конкретно использовать?
Если вы используете что-то постреляционное, например MS SQL, то есть возможность определить custom datatypes и в них реализовать свои функции сравнения. Всё равно будет медленнее, чем в чистой памяти, но может работать более-менее приемлемо.
Для остальных бы ситуаций я бы рекомендовал просто держать в памяти write-through кэш, который поднимать при необходимости из базы.
_DK>Это тоже понятно, но с иерархической кластеризацией проблема в том, что при каждом добавлении нового объекта надо перестраивать дерево (в теории дерево может полностью измениться).
Полностью — вряд ли. Это из интуитивных соображений. Но я могу ошибаться.
_DK>Кроме того, для ее расчета необходима матрица расстояний каждый с каждым (ну либо пересчет на каждом шаге).
Ну, если всё более-менее хорошо, то высоки шансы быстро найти один из существующих кластеров и вставиться в него.
Тут же всё сильно зависит от частоты изменений относительно запросов на поиск — "индексы" всегда ускоряют чтения и замедляют записи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.