powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Опять про varchar(n)
25 сообщений из 173, страница 6 из 7
Опять про varchar(n)
    #38727357
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. Я не считаю безразмерный varchar хорошей фичей, но не возражаю против таковой
2. Длинная арифметика нужна (с точностью больше 18), но это не значит, что она будет безразмерной
3. Как оно там сортируется это отдельный вопрос и вообще мало зависит от того есть безразмерные типы или нету
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727360
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovNickDeeещё увидел
Повторяю вопрос медленно: кодить всю эту хрень ты будешь?

Я ж тебе ответил вопросом на вопрос. Какие проблемы с новыми разработчиками?
Они приходят но отбриваются?
Они не приходят?
Почему разработчиков всего пять?
Спонсоры дают мало денег?
Или ты мне предлагаешь пройти этот путь и на себе понять что там не так, кто виноват и что делать с упырями? :)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727369
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис2. Длинная арифметика нужна (с точностью больше 18), но это не значит, что она будет безразмернойЕсли бы был "выход в яву" из хранимок ФБ, то все вопросы по длинной арифметике ушли бы в небытиё. В том числе и про размеры.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727377
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeИли ты мне предлагаешь пройти этот путь и на себе понять что там не так, кто
виноват и что делать
Ага, именно так. Тогда мы и увидим что эти твои "увиденные косяки" могут принести
хорошего, а что - плохого. А Таблоид позаботится чтобы продемонстрировать с цифрами в
руках насколько твои "безразмерные типы" будут тормозить.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727379
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovА Таблоид позаботится чтобы продемонстрировать с цифрами в руках насколько твои "безразмерные типы" будут тормозить.я в упор не понимаю, для чего нужна сортировка сверхдлинных строк. Кто будет глаза ломать об них, да еще учитывая, что на мониторах они всё равно не отобразятся даже в 1% своей длины ?
Сами по себе длинные строки (большие числа ?) - может, и нужны где-то. В криптиграфии с открытым ключём, например. Но это не СУБДшная задача таки. Совсем.
ЗЫ. И даже если представить, что сортировка таких строк позарез нужна, что мешает сделать таблицу со 100 полями varchar(100), в которых эти строки будут в "раздробленном виде", и выполнять из неё 100 раз заливку в GTT1 с order by F_01, затем из GTT1 в GTT2 с order by F_02, затем обратно - из GTT2 в GTT1 с order by F_03 и т.д. до 100-го поля ? Может, и выглядит как бред, но эти 100 заливок-сортировок если и будут во что-то упираться, то точно не в размер памяти. В эффективность нынешнего доступа к GTT "почти как" к FIXED-таблицам - да, будут. Но ежели ФБ-светила когда-нибудь подправят GTT-консерваторию, или вообще сделают таблицы в памяти (a'la mon$), то проблема вообще исчезнет.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727389
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидDimitry SibiryakovА Таблоид позаботится чтобы продемонстрировать с цифрами в руках насколько твои "безразмерные типы" будут тормозить.я в упор не понимаю, для чего нужна сортировка сверхдлинных строк. Кто будет глаза ломать об них, да еще учитывая, что на мониторах они всё равно не отобразятся даже в 1% своей длины ?
Так без разницы по чему сортировать, хоть по ID, всё-равно запись в памяти хранится по объявленной в метаданных длине.
Попробуй написать функцию, которая аппит варчар:
Код: sql
1.
2.
3.
4.
DECLARE EXTERNAL FUNCTION UpperStr
    VARCHAR(32000)
RETURNS VARCHAR(32000) FREE_IT
ENTRY_POINT 'UpperStr' MODULE_NAME 'str_module';


а дальше попробуй иcпользовать её:
Код: sql
1.
2.
create table T(Id integer, Name varchar(20), CreationTime timestamp); -- 1 000 000 записей
select Id, UpperStr(Name) from T order by CreationTime;


Размер одной записи выборки около 32 килобайт. Чтобы посортировать миллион таких в памяти, нужно около 32ГБ памяти.
Как решить проблему? Да элементарно, нужно объявить функцию:
Код: sql
1.
2.
3.
4.
DECLARE EXTERNAL FUNCTION UpperStr20
    VARCHAR(20)
RETURNS VARCHAR(20) FREE_IT
ENTRY_POINT 'UpperStr20' MODULE_NAME 'str_module';


И писать
Код: sql
1.
select Id, UpperStr20(Name) from T order by CreationTime;


А как же быть если нужно такое делать и для других таблиц, где размер варчара например 100?
Да элементарно, нужно объявить функцию:
Код: sql
1.
2.
3.
4.
DECLARE EXTERNAL FUNCTION UpperStr100
    VARCHAR(100)
RETURNS VARCHAR(100) FREE_IT
ENTRY_POINT 'UpperStr100' MODULE_NAME 'str_module';


И писать
Код: sql
1.
select Id, UpperStr100(Name) from T1 order by CreationTime;


А как же быть если варчаров много разных? Да элементарно, нужно объявить много функций, по количеству варчаров, по шаблону:
Код: sql
1.
2.
3.
4.
DECLARE EXTERNAL FUNCTION UpperStrN
    VARCHAR(N)
RETURNS VARCHAR(N) FREE_IT
ENTRY_POINT 'UpperStrN' MODULE_NAME 'str_module';


И писать
Код: sql
1.
select Id, UpperStrN(Name) from TN order by CreationTime;


*ботня, не правда ли? :)
Это то, на что обрекает пользователей текущая реализация VARCHAR(N).

Кстати в Firebird есть системная функция Upper, которая удивительным образом возвращает не varchar(32000), а varchar(длина параметра). А ка же быть не системным функциям?
Кстати, а если бы была системная функция Str2Hex, то варчар какой ширины она бы возвращала? длина_параметра * 2? А обратная бы делила на два? :) А как написать такую функцию используя механизм UDR? Входной параметр блоб и выходной блоб?
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727392
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee,

гнусный ты провокатор.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727401
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvNickDee,

гнусный ты провокатор.
Да просто с такими удобствами вы весь userbase растеряете. Попробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа string[n]. Понравится тебе?
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727432
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee,

ты вообще читаешь чужие сообщения. Сортировка широких выборок может делаться по другому. Читай и пробуй 13198664 .

P.S. Что ещё кто-нибудь пользуется UDFкой переводящей строку в верхний регистр?
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727433
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeДа просто с такими удобствами вы весь userbase растеряете. Попробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа string[n]. Понравится тебе?
ты действительно думаешь, что все прогрессивное человечество крутящее базы на ораклах, мссклях, мускулях и постгресах уже давно отказалось от ограничений на длину строки и юзают исключительно безразмерные типы? Смею тебя заверить, все с точностью до наоборот.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727436
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee
Код: sql
1.
select Id, UpperStr(Name) from T order by CreationTime;

Размер одной записи выборки около 32 килобайт. Чтобы посортировать миллион таких в памяти, нужно около 32ГБ памяти.Ты бы проверил вот это:
Код: sql
1.
select id from (select id from t order by creationtime) x join t on x.id=t.id;

Ну да, тут будет два раза обращение к `t`, но тем не менее сортировка потребует (20+4+4)*1'000'000 байт - 20=заголовок записи, 4 байта на id, 4 байта на timestamp (или 3 ?).

ЗЫ. Ну и про спецбилд от ДЕ, где сортировка делается примерно так, как показано, но только соединение там идёт по rdb$db_key, - ты в курсах, конечно, и тестировал его ?
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727438
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

Код: sql
1.
select id, UpperStr(Name) from (select id from t order by creationtime) x join t on x.id=t.id;


поправил.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727439
Cobalt747
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

Так что мешает?
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727442
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeekdvNickDee,

гнусный ты провокатор.
Да просто с такими удобствами вы весь userbase растеряете.Здесь на скуле, Джудж не хочет новый раздел создавать, пока не соберется определенное минимальное количество тем или желающих. (А уж создать раздел в тыщи раз легче, чем новый функционал сервера.) И ничего, не уменьшаются юзеры.

Да, в принципе, чем больше возможностей, тем лучше. Только совершенно очевидно, что сначала надо делать более востребованные возможности, а потом - менее. А твоем случае, например насчет безрармерного varchar-a я не вижу каких-то особых причин его вводить, кроме банального "мне лень подумать, какие варчары будут тут и там, и легче лепить везде одно и то же. А потом поныть про проседание производительности".
То же и со сверхдлинными числами. Неплохо бы привести пример, в какой области они будут использоваться (именно сверхдлинные, а не, скажем, длиной в 36 позиций). А то я например знаю только одну область, и там базы данных - нечто совсем постороннее.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727444
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cobalt747,

здравый смысл. Ограничение длины - это констрейнт, который в большинстве случаев вполне успешно завязывается на бизнес-логику. Исключения бывают, конечно же, но раздувать из этого истерику в стиле "шеф, все пропало!" глупо.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727453
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeПопробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа
string[n].
Молодой, длинные строки появились впервые в Delphi 2. До этого весь мир десятилетиями жил
на строках с ограничением размера и не жужжал.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727477
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Засрали тему, ироды.

Скопипастю, чтобы не затерялось:

Гаджимурадов Рустам> Alexander A. Sak> Как постепенно уходящий от FB в Postgres

Можно поподробнее на эту тему? Причины, описание самого процесса
(с перечнем технологий и библиотек, если несложно), впечатления и пр.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727611
Alexander A. Sak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я помню. Времени не было подумать. Ну вот подумал.

Основной мотив -- попробовать новенького. Остальное, наверное, вторично.

Как это было у меня. Клуб анонимных отказников от Firebird.
Начиналось все лет 13-15 назад. Основная БД была Оракл, разработка клиента -- Delphi. Попутно был левый проект -- приемная комиссия ОмГПУ. Программа выросла из штанишек Клариона, потом из штанишек Парадокса. На что переходить? Вариантов при тотальной Win98 не было: только Firebird. Пару лет даже жили с сервером на Win98.
Клиента, которого делал на основной работе адаптировал под Firebird. Пошел мегапрофит: для левого проекта писать на Delphi не надо, все решалось исключительно настройками и хранимыми процедурами. Если возникали какие-то потребности, дорабатывался клиент на основной работе. Начальство было в курсе и было совсем не против.
Потом появился второй левый проект: СПИД-Центр. Там все аналогично: клиент все тот же, системная серверная часть перекочевала из приемной комиссии.

В 2006 уволился с основной работы. На новой -- все тот же Оракл и ничего кроме него. Левые проекты продолжались, но уже вяло. Потом на основной работе начался проект на джаве, началось погружение в JEE. Delphi совсем ушел на задний план. Года с 2009 в моем окружении стал пропадать Виндовс. В 2011 закончился СПИД-Центр: их возможности совсем перестали пересекаться с моими желаниями. В 2013 закончилась приемная комиссия ОмГПУ: начальство решило, что 1С -- решение всех проблем. В 2013 же взялся за замену 1С в магазине, занимающимся мебельной фурнитурой. Почему так -- тема другого поста, наверное.

Итак 2013 год. Винды нет нигде, даже в магазине мебельной фурнитуры. Там везде Убунта. Я уже лет 7 не занимаюсь Delphi. Новый проект. Чем в такой ситуации Firebird лучше, чем Postgres? Был дан ответ: ничем. Оба устанавливаются одним чекбоксом, заказчику PG даже кажется более правильным выбором, у меня есть желание покачать скилл по новой БД. Плюс на основной работе начальство озаботилось стоимостью лицензий на Оракл и решило часть нагрузки перенести на PG. Тоже в кассу оказалось. Вот так я и очутился в стане пользователей Постгреса.

Стоит отметить, что в выборе PG<=>FB еще повлияло наше сообщество FB. Какое-то оно повышенно снобистское что ли. Единственный человек, кого это утверждение на 100% не касается -- Дима Еманов. Такое впечатление сложилось еще со времен NNTP-рассылки. Не помню уже даже где она была. На Epsilon? Google? Помню, ловил себя несколько раз на мысли, что если бы знал, что завсегдатаи такие грубияны, поискал бы что-нибудь другое. Просто из вредности. Когда пришлось выбирать, это тоже сыграло какую-то роль.

Спасибо за внимание.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727649
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovNickDeeПопробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа
string[n].
Молодой, длинные строки появились впервые в Delphi 2. До этого весь мир десятилетиями жил
на строках с ограничением размера и не жужжал.

Двести лет назад электричества не было. И "удобства" были во дворе, когда там минус 40. Кто-то жужжал? И без компов обходились.

Скажи лучше как мне универсально для строк задекларировать функцию Quote(S), которая бы квотила мне S. Сейчас получается вот такая гадость:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
create table TT(Id integer, S varchar(10));

-- 1M записей
insert into TT select row_number()over(), rpad('',10, uuid_to_char(gen_uuid())) from rdb$types,rdb$types,(select 1 i from rdb$types rows 20) rows 1000000; 

create or alter function QUOTEB (
    S blob sub_type text)
returns blob sub_type text
AS
begin
  return '"' || S || '"';
end

create or alter function QUOTE (
    S varchar(8000)) -- 8000 потому что база UTF8
returns varchar(8002)
AS
begin
  return '"' || S || '"';
end

create or alter function QUOTE253 (
    S varchar(253))
returns varchar(255)
AS
begin
  return '"' || S || '"';
end

create or alter function QUOTE10 (
    S varchar(10))
returns varchar(12)
AS
begin
  return '"' || S || '"';
end

select list(S) from TT -- 920ms
--
PLAN (TT NATURAL)
------ Информация о производительности ------
Время подготовки запроса = 31ms
Время выполнения запроса = 920ms
Среднее время на получение одной записи = 920,00 ms
Current memory = 36 929 376
Max memory = 104 864 496
Memory buffers = 2 048
Reads from disk to cache = 3 790
Writes from cache to disk = 545
Fetches from cache = 2 009 416

select list('"' || S || '"') from TT -- 1s 482ms
--
PLAN (TT NATURAL)
------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 1s 482ms
Среднее время на получение одной записи = 1 482,00 ms
Current memory = 37 214 384
Max memory = 104 864 496
Memory buffers = 2 048
Reads from disk to cache = 3 789
Writes from cache to disk = 846
Fetches from cache = 2 009 660

select list(QuoteB(S)) from TT -- 29s 750ms
--
PLAN (TT NATURAL)
------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 29s 750ms
Среднее время на получение одной записи = 29 750,00 ms
Current memory = 475 539 568
Max memory = 606 101 632
Memory buffers = 2 048
Reads from disk to cache = 3 789
Writes from cache to disk = 868
Fetches from cache = 2 009 660

select list(Quote(S)) from TT -- 15s 850ms
--
PLAN (TT NATURAL)
------ Информация о производительности ------
Время подготовки запроса = 47ms
Время выполнения запроса = 15s 850ms
Среднее время на получение одной записи = 15 850,00 ms
Current memory = 37 003 592
Max memory = 104 864 496
Memory buffers = 2 048
Reads from disk to cache = 3 789
Writes from cache to disk = 865
Fetches from cache = 2 009 660

select list(QUOTE253(S)) from TT -- 5s 179ms
--
PLAN (TT NATURAL)
------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 5s 179ms
Среднее время на получение одной записи = 5 179,00 ms
Current memory = 37 198 640
Max memory = 104 864 496
Memory buffers = 2 048
Reads from disk to cache = 3 789
Writes from cache to disk = 618
Fetches from cache = 2 009 660

select list(Quote10(S)) from TT -- 4s 696ms
--
PLAN (TT NATURAL)
------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 4s 696ms
Среднее время на получение одной записи = 4 696,00 ms
Current memory = 36 948 184
Max memory = 104 864 496
Memory buffers = 2 048
Reads from disk to cache = 3 789
Writes from cache to disk = 849
Fetches from cache = 2 009 660


Зы: понятно что правильный квотинг должен быть не просто слева и справа, но и с задваиванием символа " внутри строки. Но это уже к сути не относится.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727658
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeкак мне универсально для строк задекларировать функцию Quote(S), которая бы
квотила мне S.
Вопросы "как мне правильно вырвать гланды через задницу" должны оставаться без ответа.
Дабы не поощрять.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727659
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexander A. Sak> Я помню. Времени не было подумать. Ну вот подумал.
>
> Основной мотив -- попробовать новенького. Остальное, наверное, вторично.

Спасибо. Хотя это вовсе не то, что интересно было услышать...

> Там везде Убунта. Новый проект. Чем в такой ситуации Firebird
> лучше, чем Postgres? Был дан ответ: ничем.

Т.е. никакого выбора, фактически, не было, сменили даже не на
"новенькое", а на "другое". Желание изучить новую тенологию,
продукт и пр. похвально, конечно, но не как аргумент выбора.

> Стоит отметить, что в выборе PG<=>FB еще повлияло наше сообщество FB.

Есть такое дело, хотя преувеличивать нет смысла, да и вряд
ли у PG c этим лучше (особенно по некоторым критериям).
В любом случае, на фидбек и работу с СУБД это мало влияет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727660
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee,

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

В принципе я согласен с тобой в том что для процедур и функций длина строки могла бы вычисляться, в прочем как и точность numeric. Но ещё раз повторяю это задача не самая приоритетная.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727667
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денистакую функцию не стоит объявлять, проще прям в запросе присоединить кавычки.
Попобуй заквотить строку: А","B
Должно получиться "А"",""B", а не "А","B".
Так что универсально только функцией.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727673
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovNickDeeкак мне универсально для строк задекларировать функцию Quote(S), которая бы
квотила мне S.
Вопросы "как мне правильно вырвать гланды через задницу" должны оставаться без ответа.
Дабы не поощрять.

По существу говори :)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38727683
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeПо существу говори :)
Прикреплённая тема, ссылка дохлая, но всё же копий в сети как грязи:
http://segfault.kiev.ua/smart-questions-ru.html#goal
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25 сообщений из 173, страница 6 из 7
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Опять про varchar(n)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]