ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Опять про varchar(n)
23 сообщений из 173, страница 7 из 7
  7  все
Опять про varchar(n)
    #38727712
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Dimitry SibiryakovNickDeeПо существу говори :)
Прикреплённая тема, ссылка дохлая, но всё же копий в сети как грязи:
http://segfault.kiev.ua/smart-questions-ru.html#goal

Я вопрос задал именно тот, который интересен.
Применить этот Quote можно например если хочется быстро закачивать большие датасеты на клиента, если не по локалке работать.
Код: sql
1.
select Id, Client, Address, DocNum, DocDate, Phones, Description from Documents where...

Это может быть драматически медленно :)
Заменяем на:
Код: sql
1.
select list(id), list(Quote(Address, '"')), list(DocNum), list(DocDate), list(Quote(Phones, '"'), list(Quote(Description, '"')) from Documents where...

Получаем профит.
На клиент придёт одна запись из 7 блобов, без большого кол-ва "туда-сюда пакетов". Нужно будет извлечь данные полей, что даже для миллиона записей будет менее одной секунды.
В полях Address, Phones и Description могут быть как запятые, так и кавычки. Поэтому в запросе мы используем функцию Quote, мегасупербыструю и универсальную (о ней я тебя и спрашиваю).
Код на клиенте примерно такой:
Код: pascal
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.
type
  TStringArray = array of string;
  TRecords = array of TStringArray;

// на скорую руку
function ExtractFieldData(const Data: string): TStringArray;
var
  Count: Integer;
begin
  Count := 0;
  SetLength(Result, GetCharCount(Data, ',') + 1);
  // Идём по Data и заполняем Result, постепенно увеличавая Count
  ...

  SetLength(Result, Count);
end;

function ExtractData(Ds: TDataSet): TRecords; 
var
  I: Integer;
begin
  SetLength(Result, Ds.Fields.Count);
  for I := 0 to High(Result) do
    Result[I] := ExtractFieldData(Ds.Fields[I].AsString);
end;

var
  Recs: TRecords;
  Ds: TDataSet;
begin
  Ds := OpenDataSet('select list(id), list(Quote(Address, ''"'')), list(DocNum), list(DocDate), list(Quote(Phones, ''"''), list(Quote(Description, ''"'')) from Documents where...');
  Recs := ExtractData(Ds);
  // дальше работаем с массивом записей как угодно.
  ...
end;


Ещё его можно применить когда нужно выгрузить данные для экспорта куда-нибудь.
...
Рейтинг: 0 / 0
25.08.2014, 00:16
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727718
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
NickDeeНа клиент придёт одна запись из 7 блобов, без большого кол-ва "туда-сюда
пакетов".
Вот только 7 блобов это и есть "большое количество туда-сюда пакетов". Гораздо быстрее
будет на той стороне выгрузить все данные в файл и уже этот файл упаковать и передавать.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 00:30
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727726
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Dimitry SibiryakovNickDeeНа клиент придёт одна запись из 7 блобов, без большого кол-ва "туда-сюда
пакетов".
Вот только 7 блобов это и есть "большое количество туда-сюда пакетов". Гораздо быстрее
будет на той стороне выгрузить все данные в файл и уже этот файл упаковать и передавать.

если между list поставить "|| ASCII_CHAR(13) || ASCII_CHAR(10) ||", то получится один блоб. Разве один блоб тоже будет неэффективно передан?
Про упаковать согласен. Ещё функцию Pack в select добавить, и чтобы возвращала бинарный блоб.
Вот кстати для выгрузки в csv:
Код: sql
1.
2.
3.
select 
  list(Quote(Id) ||',' || Quote(Client) ||',' Quote(DocNum) ||',' || Quote(DocDate), ASCII_CHAR(13) || ASCII_CHAR(10)) 
from Documents where...


Поэтому вынь да положь нам быстрый Quote :) Или ещё примеров накидать? :) Это уже тогда троллинг будет :)
...
Рейтинг: 0 / 0
25.08.2014, 01:03
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727728
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
NickDeeРазве один блоб тоже будет неэффективно передан?
Да, он будет передан менее эффективно чем упакованный файл по HTTP протоколу.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 01:13
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727729
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Dimitry SibiryakovNickDeeРазве один блоб тоже будет неэффективно передан?
Да, он будет передан менее эффективно чем упакованный файл по HTTP протоколу.
А если блоб тоже будет упакован?
...
Рейтинг: 0 / 0
25.08.2014, 01:17
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727730
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
NickDeeА если блоб тоже будет упакован?
Закачка в несколько потоков, восстановление при разрыве - всё это умеет HTTP, но не Firebird.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 01:18
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727731
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Dimitry SibiryakovNickDeeА если блоб тоже будет упакован?
Закачка в несколько потоков, восстановление при разрыве - всё это умеет HTTP, но не Firebird.

Но ведь сервер может положить блоб в табличку. А клиент может скачать этот блоб из таблички в несколько потоков, разве нет? И при разрыве связи продолжить скачивать с нужного места... раз уж мы начали мыслить широко :)
...
Рейтинг: 0 / 0
25.08.2014, 01:25
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727732
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
NickDeeА клиент может скачать этот блоб из таблички в несколько потоков, разве нет?

Нет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 01:26
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727733
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
NickDee> Заменяем на:

Ты умудрился исгадить насущную, в общем-то, необходимость
совершенно идиотским примером. Именно в таких случаях и
говорят, что нефиг, ибо голову расшибёте. (с)

> На клиент придёт одна запись из 7 блобов, без большого кол-ва "туда-сюда пакетов"

Как уже сказали - ошибаешься. Ещё интересно, зачем решать
несколько другую задачу такими непредназначенными для
неё методами, вместо накопления блобов/бинарников/ХМЛ
и пр., поклонниками которых ты являешься.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 01:27
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727734
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
NickDee> А клиент может скачать этот блоб из таблички в несколько потоков, разве нет?

Точно нет.

NickDee> И при разрыве связи продолжить скачивать с нужного места

Тоже нет. Вернее, это зависит не совсем от FB, а скорее от сетевой
подсистемы, настроек и пр.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 01:28
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727735
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Гаджимурадов РустамТы умудрился исгадить насущную, в общем-то, необходимость
совершенно идиотским примером.
Вот же хороший пример про экспорт: 16486456
...
Рейтинг: 0 / 0
25.08.2014, 01:29
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727737
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Гаджимурадов РустамNickDee> А клиент может скачать этот блоб из таблички в несколько потоков, разве нет?

Точно нет.

NickDee> И при разрыве связи продолжить скачивать с нужного места

Тоже нет. Вернее, это зависит не совсем от FB, а скорее от сетевой
подсистемы, настроек и пр.

Т.е. я не смогу создать 10 коннектов и утянуть в каждом по 1/10 блоба?
...
Рейтинг: 0 / 0
25.08.2014, 01:31
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727740
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
NickDeeГаджимурадов РустамТы умудрился исгадить насущную, в общем-то, необходимость
совершенно идиотским примером.
Вот же хороший пример про экспорт: 16486456
Да и не думаю я что насущность может быть изгажена неудачным примером. Насущность никуда не делась. Или ты всё-таки чувствуешь что "всё, пипец, не надо. Говнопример всё испортил"? :)
...
Рейтинг: 0 / 0
25.08.2014, 01:39
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727743
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
NickDeeНасущность никуда не делась.
Она давно уже не существует. С появления утильки под названием FBExport.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 01:42
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727745
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Dimitry SibiryakovNickDeeНасущность никуда не делась.
Она давно уже не существует. С появления утильки под названием FBExport.

ты уже троллишь.
...
Рейтинг: 0 / 0
25.08.2014, 01:48
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727749
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
NickDee> Вот же хороший пример про экспорт: 16486456

Я его видел. Та же чепуха.

NickDee> Т.е. я не смогу создать 10 коннектов и утянуть в каждом по 1/10 блоба?


Ааа, ты таким макаром имел в виду. ХитрО, в твоём стиле.
Но нет, сегментированные точно не получится, а потоковые -
не знаю, ими вроде итак никто не пользуется (это надо уже
у Влада/ДЕ уточнять - можно ли расшарить БЛОБ или читать
кусками с указанием нужного смещения, думаю что нельзя).

NickDee> Или ты всё-таки чувствуешь

Нет, я сказал то, что сказал - не каждой обезьяне
можно доверить гранату. Даже игрушечную. :)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.08.2014, 01:59
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38727753
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Гаджимурадов РустамНет, я сказал то, что сказал - не каждой обезьяне
можно доверить гранату. Даже игрушечную. :)
Тролльнуть решил напоследок? :) Что за ночь блин :)
...
Рейтинг: 0 / 0
25.08.2014, 02:22
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38729092
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
NickDeeбез разницы по чему сортировать, хоть по ID, всё-равно запись в памяти хранится по объявленной в метаданных длине.В общем, это... товарищ NickDee!
Уламывай как сможешь dimitr'a, чтобы он портировал фикс к CORE-4528 в 2.5.

Вот тебе достаточно широкая таблица:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
recreate table t(id int primary key, x int, y int, s1 varchar(10000), s2 varchar(10000), s3 varchar(10000)); commit;
insert into t
select
row_number()over()
,rand()*100
,rand()*100
,rpad('',10000, uuid_to_char(gen_uuid()))
,rpad('',10000, uuid_to_char(gen_uuid()))
,rpad('',10000, uuid_to_char(gen_uuid()))
from rdb$types,rdb$types,(select 1 i from rdb$types) rows 100000;
commit;

И вот два варианта получения из неё кортежей, упорядоченных по полю `y`:

var-1. Революцьонная сортировка с join'ом по rdb$db_key:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
commit; select mon$stat_id si,mon$stat_group sg,mon$max_memory_used mmu,mon$max_memory_allocated mma from mon$memory_usage order by sg,si;
out /dev/null;
set stat on;

select y.x, y.s1, y.s2, y.s3
from(
  select rdb$db_key k from t  order by y 
) x
left join t y on  x.k=y.rdb$db_key ;

set stat off;
out;
commit; select mon$stat_id si,mon$stat_group sg,mon$max_memory_used mmu,mon$max_memory_allocated mma from mon$memory_usage order by sg,si;

var-2. Обычный стиральный порошок:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
commit; select mon$stat_id si,mon$stat_group sg,mon$max_memory_used mmu,mon$max_memory_allocated mma from mon$memory_usage order by sg,si;
out /dev/null;
set stat on;
select x,s1,s2,s3 from t order by y;
set stat off;
out;
commit; select mon$stat_id si,mon$stat_group sg,mon$max_memory_used mmu,mon$max_memory_allocated mma from mon$memory_usage order by sg,si;

И получаем:

trace для var-1 :
 
4942 ms, без всякого превышения TempCacheLimit'a
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Statement 58:
-------------------------------------------------------------
select y.x, y.s1, y.s2, y.s3
from(
  select rdb$db_key k from t order by y
) x
left join t y on x.k=y.rdb$db_key
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Select Expression
    ->  Nested Loop Join (outer)
        -> Sort (record length: 24, key length: 8)
            -> Table "T" as "X T" Full Scan
        -> Filter
            -> Table "T" as "Y" Access By ID
                -> DBKEY
100000 records fetched
   4942 ms, 1245290 read(s), 4 write(s), 1900056 fetch(es)

Table                             Natural     Index    Update
*************************************************************
T                                  100000    100000
trace для var-2 :
 
8073 ms, общий расход TempSpace - около 3 Гб
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Statement 61:
----------------------------------------------------
select x,s1,s2,s3 from t order by y
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Select Expression
    -> Sort (record length: 30040, key length: 8)
        -> Table "T" Full Scan
100000 records fetched
   8073 ms, 497974 read(s), 1000056 fetch(es)

Table                             Natural     Index 
****************************************************
T                                  100000


Ну, и напоследок - результаты в isql (mon$memory_usage.max_memory_xxx):

var-1:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SI      SG                   MMU                   MMA
== ======= ===================== =====================
 1       0            2452776928            2458869616  -- before query
 2       1               2269456               5177344  -- before query
. . .
SI      SG                   MMU                   MMA
== ======= ===================== =====================
 1       0            2457418568            2463690464 -- after query
 2       1               6840984               9801584 -- after query

var-2:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SI      SG                   MMU                   MMA
== ======= ===================== =====================
 1       0            2457418568            2463690464  -- before query
 2       1               6840984               9801584  -- before query
. . .
SI      SG                   MMU                   MMA
== ======= ===================== =====================
 1       0            4541590608            4547998760  -- after query
 2       1            2091013024            2094108672  -- after query

Как говорится: кому надо - сам поймёт, куда дальше строчить письмена... ;-)
...
Рейтинг: 0 / 0
26.08.2014, 14:40
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38729396
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидУламывай как сможешь dimitr'a, чтобы он портировал фикс к CORE-4528 в 2.5.Кажись, не надо уламывать :-)
Судя по SF.net SVN: firebird:[59999] firebird/branches/B2_5_Release:
автор+ 2014-08-25 13:40 dimitr
+ M src/jrd/Optimizer.cpp
+Fixed CORE-4530: DB_KEY based join of two tables may be ineffective.- всё теперь там будет хорошо, заживём по-новому! :-)
...
Рейтинг: 0 / 0
26.08.2014, 18:36
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38729406
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидзаживём по-новому
это только тебя, извращенца, интересуют обходные пути. Все остальные в этом топике хотят, чтобы летало "искаропки".
...
Рейтинг: 0 / 0
26.08.2014, 18:48
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38729422
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Dimitr!
You wrote on 26 августа 2014 г. 19:04:49:

DimitrТаблоид> заживём по-новому
> это только тебя, извращенца, интересуют обходные пути. Все остальные в
> этом топике хотят, чтобы летало "искаропки".
я даже больше скажу.
восходит на востоке, заходит на западе - НИЧЕГО НЕ НАДО ТРОГАТЬ.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.08.2014, 19:07
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38731026
Сисдба Мастеркеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сисдба Мастеркеевич
Участник
> Автор: NickDee
>
> Т.е. я не смогу создать 10 коннектов и утянуть в каждом по 1/10 блоба?
>

substring ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.08.2014, 23:54
| Ответить | Цитировать | Написать  
Опять про varchar(n)
    #38731058
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Сисдба Мастеркеевич> substring ?

Это будут 10 отдельных разных БЛОБов, а не оригинальный.
Хотя технически - да, на клиенте их можно будет склеить и
получить идентичный (по содержимому) с оригиналом
(но всё равно другой).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.08.2014, 01:49
| Ответить | Цитировать | Написать  
23 сообщений из 173, страница 7 из 7
  7  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Опять про varchar(n)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38727737&tid=1563372]:
 0ms
get settings:
 6ms
get forum list:
 15ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 178ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 77ms
get tp. blocked users:
 1ms
others: 195ms
total:  486ms
созд. / загр.: 486ms
x
x
Закрыть


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