Здравствуй уважаемый All!

Задавал этот вопрос на форуме sybase.ru, но что-то там уже неделю тишина гробовая.

Сидел тут на досуге размышлял и вот такая мысль меня посетила:
(Сразу оговорюсь, что речь идёт о ASA 9)
Насколько я правильно вычитал в документации для ASA без разницы какой тип
использовать CHAR, VARCHAR или LONG VARCHAR. Точнее есть подозрение, что с
третим не всё так гладко, но речь сейчас не об этом. То есть ведёт себя ASA
при использовании этих типов примерно одинаково: если строка<=254 байт, то
используется паскалевский тип представления с длиной строки в первом байте,
если больше, то... чего-то там ещё, посложнее. Причём ASA не добавляет
пробелы в конце строки, если её длина меньше указанной максимальной при
создании таблицы, то есть хранятся только данные (вот здесь кстати вопрос по
ходу: в тех СУБД, где пробелы добавляются, они реально хранятся в базе, или
приклеиваются динамически при работе со строками?). Но опять-таки, AFAIR ASA
отводит по умолчанию для каждой строки место, которое заявлено в
максимальных длинах строк для того, чтобы избежать фрагментации при
изменении данных. Вот теперь собственно вопрос: С одной стороны есть желание
снизить кол-во места необходимое для хранения данных в базе, максимально
рационально его использовать, с другой стороны не хочется слишком жёстко
ограничивать максимальный размер хранимой строки, чтобы потом было меньше
геморроя, если вдруг кто-нибудь решит забить в поле мега-строку. Кто как
поступает? Поделитесь опытом...

И ещё вопрос вдогонку: генерируются ли какие-либо исключения/ошибки при
попытке пользователя забить в поле строку с длиной больше максимальной или
она просто втихую обрезается до нужной длины? Т.е. если я хочу в клиентском
приложении пользователю сказать: "нехорошо, дорогой, такие мега-строки
забивать" надо ещё constraint'ы создавать, чтобы это отловить или
ограничения на длину достаточно?

Спасибо за ответ!

ASCRUSНасчет хранения полей Вы ошибаетесь - ASA не резервирует всю длину для varchar полей и хранит ровно столько, сколько есть.

Теперь понятно. Я собственно вот из-за чего неправильно себе всё это представил: Если в Цетрале открыть свойства таблицы и выбрать закладку Miscellaneous, то там будет находиться такая опция "Free space" и вот что про неё написано в хелпе:

Free space. Specifies the amount of free space you want to reserve for each table page. The free space is used if rows increase in size when the data is updated. If there is no free space in a table page, every increase in the size of a row on that page requires the row to be split across multiple table pages, causing row fragmentation and possible performance degradation.

То есть, я это понял, как место для роста размера поля, а надо понимать как место для роста всей строки. Когда ещё раз перечитал, всё вроде на свои место встало. Только вот теперь другой вопрос появился: нужно ли менять 200 байт стоящие у меня по умолчанию и, если да, то на что? Скажем, в строках хранится информация, длина которой может меняться от средней где-то +-50% (ФИО, например).

ASCRUSЛично для меня если известная максимальная длина фамилии человека 40 знаков, то значит в базе можно на всякий пожарный поставить 50. Но уж никак не 500 - не будет таких мега-фамилий по любому :)

А 40 знаков это не мега-фамилия? :)