StressmanStalker4,
НО! к сожалению все что больше char(254) sybase начинает хранить и использовать полностью аналогично long varchar, поэтому лучше на простых данных не превышать этот порог.
Все относится к АСА 9 версии и ниже. Начиная с поддержки nchar, то есть 10 версии, порог хранения char на странице составляет 128 байт. Однако появились новые возможности оптимизации хранения текстовых данных, позволяющие хранить тексты сжатыми (compressed) и определять, какая их часть будет хранится на текущей странице записи и сколько ее будет продублировано на прочих страницах хранения BLOB (операторы INLINE и PREFIX).

Ggg_oldА где об этом сказано в документации? Насколько я помню, то оговариваются такие моменты:
- поля типа BLOB хранятся отдельно
- остальное хранится на страницах. Фрагментация заполнения страниц зависит от cfvjuj размера страницы и параметра pctfree. Поэтому размер страницы желательно выбирать такой, что-бы в нее влазила хотя-бы одна или несколько записей целиком с минимальными потреями на обрезку.
Все сказано в BOL :)

Character data types/About:
All character data values are stored in the same manner. By default, values up to 128 bytes are stored in a single piece. Values longer than 128 bytes are stored with a 4-byte prefix kept locally on the database page and the full value stored in one or more other database pages. These default sizes are controlled by the INLINE and PREFIX clauses of the CREATE TABLE statement.

CREATE TABLE/SQL Syntax
The INLINE and PREFIX clauses are for use with storing BLOBs (character or binary data types only). Use the INLINE clause to specify the maximum BLOB size, in bytes, to store in the column. BLOBs that exceed the INLINE value are stored outside of the row in table extension pages. Use the PREFIX clause to specify how many bytes of the BLOB to duplicate and store with the row. Prefix data can improve performance when processing requests that need only the prefix bytes of a BLOB.

if you set INLINE to a large value, and all the BLOBs are stored inline, row processing performance may degrade. If you set PREFIX too high, you increase the amount of disk space required to store BLOBs since the prefix data is a duplicate of a portion of the BLOB.

White OwlASCRUSPrefix data can improve performance when processing requests that need only the prefix bytes of a BLOB.а вот тут поподробнее пожалуйста. Как именно можно достать ну скажем первые 64 байта из блоба чтобы этот самый prefix начал работать?
Вот что я понял из скупых абзацев BOL 11 по INLINE и PREFIX (в BOL 10 все криво написано было):
1. Если длина char или BLOB меньше или равно длины, заданной в INLINE, то значение хранится в записи. Таким образом, имея в ASA INLINE 256 (который задается по умолчанию), можно сказать, что все строки, длина которых меньше или равна 256 байтам, хранятся в записях
2. Если длина char или BLOB больше длины, заданной в INLINE, то значение поля хранится на отдельной странице БД (таким образом, при чтении записи будет считана не одна, а две и более страницы), а в записи хранится 4 байтовый указатель на страницу, где хранится значение.
3. Для того, чтобы ускорить поиск в фильтре и вывод по значениям полей, хранящимся в отдельных страницах (п.2), можно через PREFIX указать, какое кол-во байт от начала значения поля должно дублироваться и хранится в самой записи (по умолчанию PREFIX равно 8 для текстовых полей и 0 для бинарных полей).
4. Если в пределах одной таблицы две или более колонки одной записи содержат одинаковое значение BLOB, хранящееся на отдельной странице (то есть не попадающим под INLINE), где значение второй и более колонок вводилось через ссылку на другую колонку (например UPDATE table SET column2=column1), то сервер вместо дублирования значения поля, просто зашарит страницу и приравниваемым колонкам установит ссылки на нее же (BLOB Sharing).

Итого:
Увеличивая INLINE мы уменьшаем при выполнении запросов кол-во чтения дополнительных страниц, содержащих длинные значения, но одновременно увеличиваем размер записи, что приводит к уменьшению их максимального кол-ва на странице, а значит увеличению чтения основных страниц при выполнении запросов. Если поле имеет большую длину и не часто используется в запросах, то имеет смысл установить INLINE в 0.

Увеличивая PREFIX мы увеличиваем размер записи, уменьшаем кол-во записей на страницах, увеличиваем кол-во чтений основных страниц. Чтобы добиться при выполнении запросов уменьшения кол-ва чтений дополнительных страниц, использование PREFIX имеет смысл в следующих случаях:
1. если используется поле LIKE 'Значение%', где длина Значение не превышает длины PREFIX
2. если в возвращаемом наборе поле обрезается до длины, меньше или равной в PREFIX функциями CONVERT или CAST, например SELECT CAST(varchar(<ДлинаПрефикса>), Поле) AS Поле FROM Table (стоит помнить, что для использования обрезания стринговых полей функциями конвертации необходимо установить опцию string_rtruncation в OFF.
Остальные функции (LEFT, SubStr, PatIndex, Location, ...) - не умеют работать с префиксами и таким образом их использование приведет к чтению дополнительных страниц.

P.S. Все вышенаписанное про PREFIX обнаружено мной опытно-экспериментальным путем и в BOL не имеет подтверждения.

White OwlASCRUSОстальные функции (LEFT, SubStr, PatIndex, Location, ...) - не умеют работать с префиксами и таким образом их использование приведет к чтению дополнительных страниц.А вот это плохо...
Ладно, значит для вытаскивания сигнатурф файла лежащего в блобе это все не применимо. Жаль... Ну значит будем по старинке дополнять блоб кучкой полей описывающих файл.
Ну почему не применимо ? Я же написал - есть поддержка CONVERT, CAST и LIKE. Если сигнатура файла находится в начале и занимает не сильно много байт, то этих функций будет вполне достаточно.