Интересующийся ТСИнтересно - у "взрослых" СУБД, типа Оракл или МС СКЛ - точно так же, нужно явно определять размер?
У FB хватает странных ограничений, например буквально вчера он у меня отказался создать индекс по varchar(300). На 2.1 работал, а на 2.0 ниасилил.

Про МС не скажу, а в Оракле довольно трудно придумать, когда бы требовалось указать cast с размером. Он и без размера-то употребляется редко, в основном для подстановки в запрос выборок из табличных функций.

Dimitry SibiryakovС теми, кто не ниасилил документацию, случаются и не такие неприятности...
Ага. Видать, где-то в сети лежит такая волшебная документация, что от её асиливания лимиты чудесным образом раздвигаются

dimitrв 2.0 размер страницы 1К небось?
Представления не имею - это не моя база, пользователи скрипта пожаловались на ошибки. Впрочем, в 2.1 та же база, создававшаяся по идее теми же скриптами (просто файл, который я когда-то скопировал к себе, представления не имею, какой версией FB он поддерживался до копирования). Так что либо размер страницы одинаковый, либо дефолтовый.

dimitrа 2.1 втихую апгрейдит его до 4К, т.к. меньше не поддерживает.
Хм. На месте FB-разработчика я бы высказался на тему такой самостоятельности. Имхо, если инструмент не может выполнить прямую и недвусмысленную команду, он должен выдать ошибку, а не тихой сапой "делать что могу".

dimitrВ оракле ведь тоже макс. размер ключа зависит от размера блока.
Зависит. Только большинство разработчиков ни разу в жизни на это ограничение не натыкаются, поскольку оно чаще всего порядка 6500 байт в то время как varchar ограничен 4000 байт.

Если обратите внимание, я не против ограничений, но отметил, что в FB они порой довольно странные и неожиданные (с точки зрения моей версии здравого смысла). В данном случае мой здравый смысл говорит, что создание индекса по двум memo-полям - ситуация крайне редкая и бессмысленная, то есть ограничение практически роли не играет. Создание индекса по одному бизнес-полю (ограничение длины взято на основе данных государственного справочника + запас) - ситуация достаточно частая, и невозможность это сделать - для меня была неожиданна.

dimitrа чем страница 4К хуже для разработчика, чем 1К? Все как работало, так и будет.
До тех пор, пока "всё" соответствует ожиданиям разработчиков СУБД. Но всегда найдётся какой-нибудь вывернутый функционал, который из-за этого начнёт глючить. Для FB я вряд ли приведу разумный пример, с бедра - if page_count * 1024 * 0.9 > file_limit then print "Пора заводить новую базу". Скажем, в Oracle мне помнится подобное, когда была создана таблица с извратными параметрами вроде initial 8K next 80K pctincrease 1000 maxextents 10, а потом вышел девятый оракл, и этот скрипт натравили на uniform size табличное пространство - внедрились, всё чудесно, и вдруг система рухнула по максимальному объёму таблицы.

dimitrв которых тупые разработчики в эпоху царя гороха беспричинно заложились на размер 1К.
А если умные и причинно? :) Это вечный вопрос.. по мне, лучше исправить падающий скрипт в явном и очевидном месте, нежели отлавливать тонкие проблемы хрен знает где только потому, что СУБД считает себя умнее разработчика.

dimitr6.5К оно на дефолтном (и заодно минимальном?) блоке 8К. Если бы оракл поддерживал размер блока в 1К,
То либо индекс допускал бы превышение размера блока, либо я ругался бы на индексы и в оракле тоже :) Де-факто же в оракле есть пожалуй что два дурных ограничения: 30 байт на размер идентификатора и 1000 значений внутри in(...) списка. Во всяком случае это что вспомнилось сходу.

Теоретически минимальный блок 4К. Практически поддержка в одном экземпляре табличных пространств с разным размером блока - геморрой очччень сомнительной полезности, поэтому подавляющее большинство экземпляров работают с 8К блоками, небольшое количество - с 16К.

dimitrкак видим, никакой фантастики тут нет.
А магии вообще не существует. "Со стороны разработчика продукта" я понимаю наличие ограничений. "Со стороны потребителя продукта" я полагаю, что ограничения должны соответствовать потребностям пользователя. Соответственно, со своей стороны - стороны проектировщика - я склонен говорить разработчику "вот это надо обеспечить, а как это сделать - если не знаешь, давай думать вместе".

dimitrесли бы все были такими, моя жизнь вероятно стала бы намного проще :-)
Дык все таковы, какими Вы их видите/формируете.

Я помню одну девочку, писала себе в блог лиричные грустные рассказы, интересно общалась, в основном мужская аудитория, однажды в полной растерянности опубликовала письмо анонимной доброжелательницы - мол, ты конечно добрая итп, но хочу открыть тебе глаза, мужики козлы и сволочи, а вовсе не такие, какими ты их рисуешь. Это письмо вызвало несколько спокойных комментариев типа "ну не повезло женщине", она не выдержала и объявилась отстаивать свою точку зрения, общий тон её собеседников был - мы тебя понимаем и нам тебя жалко, в итоге - уникальный случай для интернетов, имхо - она глубоко задумалась на тему "наверное таки я что-то неправильно делаю, что на меня всю жизнь клюют только козлы и именно козлы".

dimitrоба есть и в ФБ, если это утешит :-)
Да нет, не утешит. Имхо со времён минимум Oracle 8, когда оно начало конкретно мешать, можно было бы хотя бы поднять до varchar(300), если уж не придумать чего попродвинутее. А с IN() и вовсе - стандартный обход через IN(..) OR IN(..) OR IN(..) показывает сугубую искусственность, неразумность ограничения.

dimitrХотя с точки зрения ФБ-шника оракловое ограничение на размер строки в 4К тоже абсолютно дурное.
Я не очень понимаю слова "с точки зрения ФБ-шника". От них тянет флеймом. Имхо в данном случае есть точка зрения абстрактного БД-разработчика с реальными прикладными задачами. И с их точки зрения, имхо, ограничение размера строки в, допустим, 40 символов было бы невменяемым, в 200 - неудобным, а начиная, например, от 1000 где стоит граница - там и ладно, всё равно она где-то должна стоять. Я знаю случай, когда не хватило и ораклового ограничения на размер строки в 32К, но тут вопрос простой - либо оно есть, либо его (реального) нет. Второе пока делать не любят, хотя имхо это вопрос больше замшелого наследия, нежели реальной сложности.