iBase.ru Forum

Будет ли когда-нибудь возможность использовать мои домены как входные и выходные параметры в хранимых процедурах? Или это противоречит специфике процедур? Имеется в виду то, что она хранится в откомпилированном виде. Реально немного неудобно. Изменил домен описывающий варчар(1024) на варчар(4096), переконектился - во всех таблицах его использущих все пучком, ничего не надо делать, а вот в процедуры гоняющих данные по этим доменным полям приходится долго и кропотливо менять и перекомпиливать. А могло бы и все автоматом...

Дополнительный вопрос :)
Почему нету заранее предопределенного варчара равного varchar(max_varchar_size). Какой вообще смысл указывать максимальныю длину (ну разве что кроме возможности получить екцепшон при переполнении), если можно просто по умолчанию всегда использовать макимально для него допустимую. Ведь в любом случае варчар передается как на клиент так и обратно через размер+данные.

Спасибо.

entryway писал(а):Будет ли когда-нибудь

скорее да, чем нет

entryway писал(а):могло бы и все автоматом...

...отправить все твои процедуры в инвалид при некорректном альтере домена

entryway писал(а):смысл указывать максимальную длину

индексы, например

entryway писал(а):передается как на клиент так и обратно через размер+данные

вот только в базе хранится с хвостами, хоть и сжатыми

entryway писал(а):смысл указывать максимальную длину

индексы, например

А что индексы? Только что прочитал релизнотес для FB2. Нет там ограничения на длину индекса

entryway писал(а):передается как на клиент так и обратно через размер+данные

вот только в базе хранится с хвостами, хоть и сжатыми

Насколько критично?
Проверил. Создал две базы с одной таблицей в которой одно поле. В первой varchar(10) во второй varchar(32000). Сделал туда и туда инсерт миллиона записей со значением "A". В первом случае размер файла базы данных 52 мб. Во втором - 552 мб. Больше похоже не на сжатие, а на выделение "с запасом". А запас вычисляется как процент от заданной длины. Не могу, короче, теперь уяснить для себя: критично это или нет :)

entryway писал(а):Только что прочитал релизнотес для FB2. Нет там ограничения на длину индекса

плохо читал. Ключевое слово - размер страницы

entryway писал(а):Насколько критично?

сам видишь - весьма заметно

entryway писал(а):похоже не на сжатие, а на выделение "с запасом"

давай ты не будешь фантазировать, а поверишь на слово

entryway писал(а): А что индексы? Только что прочитал релизнотес для FB2. Нет там ограничения на длину индекса

Прально! 252-byte ibndex length limit is gone. И нефиг читать что там дальше шрифтом помельче сказано, глаза об него мозолить. Сказано же - 252 больше не предел. Знач нет больше никакого предела. А уж эффективность индекса по полю 32к размером и обсуждать-то нечего.

вот только в базе хранится с хвостами, хоть и сжатыми

entryway писал(а): Больше похоже не на сжатие, а на выделение "с запасом". А запас вычисляется как процент от заданной длины.

Прально. Объясни ему наконец как оно устроено. А то не знает ничего и гонит тут пургу. Смотри, ещё слова всякие непонятные начнет говорить, RLE там... Так ты его сразу по башке, воли не давай.

2 dimitr
tnx

А чего именно происходит компрессия? Всего поля, его части выходящей за старый предел в 255 символов, что-то другое. И всегда ли. Ведь на первый взгляд RLE - не соввсем то, что нужно, вернее не совсем то, что эффективно применять для "хвостов". Хвост - он ведь всегда один...

Merlin писал(а):Прально. Объясни ему наконец как оно устроено. А то не знает ничего и гонит тут пургу. Смотри, ещё слова всякие непонятные начнет говорить, RLE там... Так ты его сразу по башке, воли не давай.

Я вас умоляю, перестаньте.

компрессируется вся запись, целиком.

да, все сходится
32000/64*1000000=500мб

а какие обьективные причины сжимать не только вещественную часть, но и мнимую? IB?