Здесь N - это не количество видимых символов, а ограничение на максимальное количество байт в строке, т.е MaxBytes = N * 4;
Т.е. если я определю поле как VARCHAR(1000) (что достаточно много, если использовать WIN1251), то пользователь сможет записать туда только 4000 байт юникода, и не байтом больше.
Проблема вот в чём - в общем случае я не знаю что конкретно пользователь будет записывать в такое поле.
Может это будет просто русский текст, или английский, или европейский. А может китайский или японский. А может математическая формула. А может там будут символы из фонетического алфавита , а может это будет индийский текст , или вот такое арабское письмо с диактриками .
Т.е в общем случае я не знаю что там будет, и оценить например сколько будет занимать в байтах банальное ФИО в арабском письме (чтобы потом разделить это на 4 и прописать результат в VARCHAR(N)), я не могу.

У меня ещё проблема усугубляется тем, что я даю пользователям создавать поля в БД, и писать логику к ним. Представьте - арабский пользователь идёт в админку создавать поле для хранения ФИО, выбирает таблицу, указывает название нового поля, выбирает тип "string" и тут ему предлагают ввести максимальную длину этого поля в символах (допустим у них там есть такое понятие как символ-место, в чём я не уверен)..., он прикинул - максимум 100 символов, на ФИО. А в реальности создаётся поле не на 100 символов, а на 400 байт юникода, в которые вполне могут не войти даже 20 символов его языка.
И что с этим делать - я не знаю. Создавать все поля как VARCHAR(8000)? Это не вариант, т.к. у меня уже есть опыт с заданием стринговых полей по-дефолту как VARCHAR(255) - тормоза существенные. Создавать стринговые поля как блобы? Это тем более не вариант :)

Вопрос: если бы вы были пользователем программы (например арабским пользователем), которая позволяла бы вам создавать поля, то как бы вы хотели чтобы вас программа ограничивала - максимальной длиной в символах или количеством байт? :) Чисто попробуйте глазами пользователя посмотреть :)
Моё имхо как потенциального юникодно-арабского пользователя такое: "я готов указать только тип данных (строка)". Как программист я конечно понимаю что на данном этапе развития firebird у меня варианта только три: либо блобы, либо VARCHAR(8000), либо мучать пользователей.
Вопрос - что делать? Ни один из этих вариантов не кажется конструктивным :)

hvladNickDeeЗдесь N - это не количество видимых символов, а ограничение на максимальное количество байт в строкеС чего ты это взял ?
Из экспериментов с юникодом.
Вот скриншот из IBExpert. Первый столбец - размер в байтах.
Третья строка не влезает в VARCHAR(250):
---------------------------------------------------
Incompatible column/host variable data type.
Dynamic SQL Error.
SQL error code = -303.
arithmetic exception, numeric overflow, or string truncation.
string right truncation.
---------------------------------------------------

Это вот из этой темы: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags
Короче я после исследований уже не стал бы закладываться что одно символ-место - это максимум 4 байта :) В некоторых языках к одному символу можно приделать несколько чёрточек в разных местах, и смысл (или прочтение) символа изменится, а размер его увеличится.

wadmanNickDeeу меня уже есть опыт с заданием стринговых полей по-дефолту как VARCHAR(255)
Странно, мой опыт в 4096 не показывал тормозов... Ну да ладно.
Вот: 10592614 :)

hvladNickDeeпропущено...

Из экспериментов с юникодом.
Вот скриншот из IBExpert. Первый столбец - размер в байтах.
Третья строка не влезает в VARCHAR(250):У тебя первая строка имеет размер 258 октетов(байт), что уже опровергает твоё заявление:
Там тип VARCHAR(5000).
А вот третья строка не влезла в VARCHAR(250), как я и сказал. И понятно почему. Потому как в VARCHAR(250) можно поместить только 1000 байт, а там 1008.
А первая строка (на 285 октетов-байт) в VARCHAR(250) прекрасно разместилась.

hvladNickDeeВот: 10592614 :)Тебе там про "пальцем в небо" уже говорилось
Говорилось, а ниже ( 10593127 ) ты объяснил в чём на самом деле проблема: hvladNickDee2. Скорость работы с такими варчарами. Лично я увидел многократное ускорение от того, что вместо описания udf-функции


для varchar-полей всех длин, использовал отдельно для полей varchar(256) и ниже вот такое объявление:


Эта функция используется в триггере для логирования изменений данных поля. Причём обратите внимание, на скорость повлияло именно изменение define udf в базе, а сама процедура WriteAny в dll-ке осталась той же.Это особенности MM. Небольшие куски памяти выделяются из своих пулов, это быстро.
А вот 32K уже будет запрошено через VirtualAlloc, это медленно.

Так что VARCHAR(256) и VARCHAR(32762) - это иногда две больше разницы, независимо от "пальцем в небо" :)

NickDeehvladпропущено...
У тебя первая строка имеет размер 258 октетов(байт), что уже опровергает твоё заявление:
Там тип VARCHAR(5000).
А вот третья строка не влезла в VARCHAR(250), как я и сказал. И понятно почему. Потому как в VARCHAR(250) можно поместить только 1000 байт, а там 1008.
А первая строка (на 285 октетов-байт) в VARCHAR(250) прекрасно разместилась.
Если что, вот табличка:


Вот такой запрос


показывает результат:

Хм.
Получается что VARCHAR(N) - означает всё-таки N юникодных символов :)
Просто одно знакоместо может состоять из десятка-двух юникодных символов (думаю можно и больше).
Теперь дошло :)

Т.е 'строка' войдёт в varchar(6), а если там поставить ударение на последнюю букву, то уже не войдёт, т.к. получится уже 7 юникодных символов ('строка' + символ ударения). А если добавить по ударению к каждой букве (что юникод не запрещает), то получившаяся строка уместится только в VARCHAR(12). Так?

Dimitry SibiryakovNickDeeА вот третья строка не влезла в VARCHAR(250), как я и сказал. И понятно
почему. Потому как в VARCHAR(250) можно поместить только 1000 байт, а там 1008.

Если твоя софтина раскладывает композитные символы на части при сохранении в БД, это
проблема твоей софтины, а не БД.

Это делает firebird, чтобы проверить не превышает ли юникод-строка ограничение в N юникодных символов.
Если я правильно понимаю, то единственный способ сделать такую проверку - это декодировать utf-8 строку. Долго, но ничего не поделаешь :)
Или всё-таки проверяет количество байт? Я вот попытался в VARCHAR(250) запихнуть строку на 300 байт обычного текста (300 ansi символов) - не проканало, а на 285 байт юникодного - проканало.
Т.е. либо UTF-8 строка честно декодируется сервером для извлечения кол-ва символов, либо я чего-то не понимаю :)

Basil A. SidorovNickDeeПолучается что VARCHAR(N) - означает всё-таки N юникодных символов :)Кодовых точек (code points).
А символы (symbols) - уровнем выше и могут состоять из нескольких кодовых точек. И даже из разного количества при разных уровнях нормализации.
Т.е. более точным будет при создании пользователем поля запрашивать у него не количество символов, а количество кодовых точек (code points) :)
Я вот чувствовал что количество символов тут не подходит :)

Думаю что в доке к FB нужно написать, что N в VARCHAR(N) - это максимальное количество code points, а ни как не символов.