"Oleg LOA" <[EMAIL PROTECTED]> сообщил/сообщила в новостях
следующее: news:[EMAIL PROTECTED]
> "Dmitry Voroshin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > Да ну?
> >
> > Навскидку: substring( from 1 to X)  :)))
>
> 1) Хэш фиксированный длдины
> 2) И какой при этом будет размер хэша?
> 3) Если размер blob > x, то порядок теряется

1) В любом случае в хэше всегда есть коллизии.
2) Конечно, что я написал - ерунда.  С тем же успехом можно сортировать и
сами блобы всортировщике. Достаточно просто сравнивать сегменты по порядку.
В общем случае 99% блобов будут отличаться друг от друга уже в первом
сегменте. Правда в худшем - не будут отличаться вовсе. Сейчас, как я
понимаю, сортировщик тащит все данные внутро себя (на диск там сбрасывает).
Блобы, можно туда не тащить, а запрашивать сегменты только для сравнения. С
другой стороны нужен будет упорядоченный список этих сегментов (в памяти или
на диске).
Мутно тут всё.
Теоретически то тут проблем нет, но вот практически как всё это будет
работать и не убъёт ли это производительность сортировки это уж не мне
судить...


Ещё как вариант - индекс для BlobID в порядке их сортировки. Насколько
замедлидся вставка? Опять же не мне судить.
В обще случае, конечно, решать разработчикам. Я блобы вроде как пока не
сортирую и distinct по ним не делаю.

Хотя, с другой стороны... Уж если приравняли тектовые блобы к строкам, то
почему я  могу сортировать string(32000) а текстовый блоб, содержащий 33000
символов уже не могу?


Ответить