Здесь 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, а ни как не символов.

Dimitry SibiryakovNickDeeЭто делает firebird, чтобы проверить не превышает ли юникод-строка
ограничение в N юникодных символов.
Нет, Firebird ничего подобного не делает.
Т.е. проверяет по количеству байт, т.е. тот же N*4?
Он либо проверяет по количеству символов, либо по количеству байт.

Эксперимент. Подключаюсь к базе с win1251.


Т.е. сервер не ругнулся на 20 байт, но ругнулся на 11.
Он может так ругнуться только если считает не байты, а символы (т.е. парсит utf8-строку).

IBExpertNickDeeОн может так ругнуться только если считает не байты, а символы (т.е. парсит utf8-строку).

В данном случае ты ему подсовываешь 11 символов win1251, чтобы он упихал их в VARCHAR(10). Ему даже парсить и конвертировать ничего не надо для того, чтобы дать тебе отлуп.
Возможно. Но когда я подключаюсь через UTF8 в IBExpert, то:
1. При галке "Do NOT perform conversion from to UTF8" я получаю:
-----------------
Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Malformed string.
-----------------
даже при


2. Без галки "Do NOT perform conversion from to UTF8" я при

получаю вставленную запись, и она нормально отображается в гриде.
А при

я получаю:
-------------
Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
string right truncation.
-------------

Т.е. сервер таки честно считает количество UTF8 символов.

NickDeeТ.е. сервер таки честно считает количество UTF8 символов.
Пардон - не символов, а unicode code points :)

IBExpertУ символов UTF8 жесткая структура, которая легко валидируется. На этом этапе и длина строки в символах UTF8 легко вычисляется.Дак я про это же и говорю - вычисляется разбором строки.

IBExpertСимвол UTF8 - это последовательность от 1 до 4-х байт (теоретически - до 6). В firebird в системных таблицах это 4 байта. И по стандарту тоже 4.
Википедия своими таблицами на 6 байт конечно вводит в заблуждение.

ТаблоидNickDeeСоздавать все поля как VARCHAR(8000)? Это не вариант, т.к. у меня уже есть опыт с заданием стринговых полей по-дефолту как VARCHAR(255) - тормоза существенные. Создавать стринговые поля как блобы? Это тем более не вариантУ тебя сортировки по этим гамаль-абдель-ибн-хаттаб-аль-трампампам - предполагаются ?
Сортировки скорей всего будут. Но это не мне решать :)
Можно сделать чтобы сервер сортировал, можно сделать чтобы грид сортировал. Это настраиваемо. Но по-умолчанию - сервер.
Предполагаю что сервер лучше знает правильную сортировку для UTF8, и лучше это поручить ему. Возможно заблуждаюсь :)

IBExpertNickDeeВ firebird в системных таблицах это 4 байта. И по стандарту тоже 4.

Это максимум. Твои '1234567890' физически будут лежать именно так, занимая ровно 10 байт, а не 40.
Да я знаю что это максимум. И что ansi-символ в utf8 занимает 1 байт, а кириллический - 2.

fd00chNickDee Википедия своими таблицами на 6 байт конечно вводит в заблуждение.та же вики говорит, что в utf8 суррогатных пар нет. это логично, ведь в utf8 куда большее пространство можно затолкать, чем в utf16

Как я вижу ситуацию, о которой ты печешься в стартовом посте (теория, не проверял в реале). Прога пишет юзеру "в это поле можно вбить не больше 30 символов". Юзер, видя это сообщение, со спокойной душой вбивает 30 символов из "кудрявых" диапазонов юникода. Вбивает он их в DBEdit, который имеет кодировку utf16, та превращает текст в кучку суррогатных пар - UnicodeString длиной, скажем, 50 символов. Если у DBEdit задано свойство MaxLength=30 (Delphi проявит интеллект, ага) - случится фейл. Если нет - либа для работы с Firebird (ну или ты вручную, на худой конец) выдернет из DBEdit 50-симвльную строку в utf16, конвертнет ее в utf8, у которой длина будет как раз те самые "реальные" 30 символов и запишет в БД без исключений. Т.е. в теории проблем никаких нет. Вопрос - насколько хорошо в реале отрабатывает функция MultiByteToWideChar, которая по умолчанию занимается преобразованием utf16 -> utf8, сможет ли она максимально упаковать суррогатные пары, чтобы не вылезти за лимит, или будут нужны доп.ужимки с нормализацией и предварительной проверкой длины utf8-строки во время ввода в DBEdit
У меня нет DBEdit :)
И в первом посте не про то, чтобы ограничить пользователя. Там про создание поля юзером через админку.
Если бы был резиновый varchar, и если бы пользователь хотел специально ограничить длину заданным количеством code points , то я бы создал constraint на поле:

Либо прописал бы проверку в триггере с вменяемым сообщением.
Но не помню чтобы у меня было желание специально ограничить VARCHAR, кроме разве что для нужд хранения GUID и MD5-хэшей.
Т.е если бы был эффективный резиновый тип, я бы в 99% случаев использовал бы его.

ТаблоидNickDeeПредполагаю что сервер лучше знает правильную сортировку для UTF8, и лучше это поручить ему.Не забудь учесть, что на производительность сортировки влияет именно объявленная длина поля, а не фактическое число символов, которое в нём хранится. Кроме того, в undo-лог записи попадают также с паддингом варчаров до объявленной длины ( Тынц ).
Про это есть тикеты в трекере? :)
Я вообще удивляюсь. Вроде все знают что проблема с длинными варчарами есть, но блин ведут себя так, будто проблем нет :)
И главное когда другие советуют использовать гигантские VARCHAR(32000), то никто из разработчиков что-то не вспоминает что там есть "нюансы", и не говорит что вот там, там и там разложены грабельки :) Вот что мешает подсказать? :)

Dimitry SibiryakovNickDeeкогда другие советуют использовать гигантские VARCHAR(32000), то никто из
разработчиков что-то не вспоминает что там есть "нюансы", и не говорит что вот там, там и
там разложены грабельки :) Вот что мешает подсказать? :)
Надежда, что тот, кому такое подсказывают (кстати, я таких подсказок что-то не припомню) -
не полный дебил и понимает последствия.

Я не понимал последствий, но интуитивно чувствовал что они будут, и что мне не понравится :)
Сейчас понимаю лучше.
Кто без интуиции, тем конечно в firebird лучше не идти :) Или нужно хорошо изучать sql.ru и ibase.ru, и обязательно проверять все утверждения :) Короче путь джедая :)