Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 23 24 25 26 27 [28] 29 30 31 32 .. 36   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30196

а вгде ЭТО может понадобиться?

Posted via ActualForum NNTP Server 1.5

21 фев 19, 14:26    [21816392]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

во всём чушь. Начинания от видения что это большой блоб.
Ну ладно ещё SELECT из него сделать, но UPDATE, DELETE и INSERT это чушь 100%

В трекере было предложение LOCAL TEMPORARY TABLE в 100 раз разумней твоего.
Так же коллекции предлагали аля Оракл. Тоже умнее.
В конце концов есть плюшки из стандарта по сериализации/десериализации в JSON/BJSON
21 фев 19, 14:28    [21816396]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28051
Симонов Денис,

типа, "таблицы в памяти". Примеры, конечно, адские. Да еще плюс идея передавать rowset как параметр (домен).
Обязательно найдется кто-нибудь, кто зафигачит туда стопяццот мильонов записи, а потом будет жаловаться, почему 32битный ФБ упал, а 64битный ФБ сожрал кучу памяти.

А временные таблицы, собственно, и так в памяти (если ее хватает у ОС) находятся.
Так что, автору надо было начать с проталкивания "таблицы как параметры". А уж потом - про таблицы в памяти. Или наоборот. Главное - вначале не смешивать.
21 фев 19, 14:30    [21816400]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
kdv,

дык если он это добро ещё и наружу будет тащить вообще весело будет. Сейчас в FB нет типов входных и выходных параметров которые могут использоваться только в рамках PSQL.
21 фев 19, 14:41    [21816417]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

к слову. Я в рамках эксперимента с UDR вполне себе закатал выборку SELECT в BLOB в формате JSON
21 фев 19, 14:42    [21816420]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис
kdv,

дык если он это добро ещё и наружу будет тащить вообще весело будет. Сейчас в FB нет типов входных и выходных параметров которые могут использоваться только в рамках PSQL.
Там же написано, что вся работа с ROWSET может производится только внутри BEGIN..END, а при необходимости "вытащить наружу" (на клиента) надо использовать FOR SELECT..DO SUSPEND внутри BEGIN..END. Ты невнимательно читал.
21 фев 19, 15:07    [21816466]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
kdv
Симонов Денис,

типа, "таблицы в памяти". Примеры, конечно, адские. Да еще плюс идея передавать rowset как параметр (домен).
Всяко лучше, чем из глубины в дюжину ХП тащить записи через SUSPEND без индексов и джойнить их по натуралу.
21 фев 19, 15:10    [21816477]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

ну и использовал бы стандартные наработки из других серверов. Зачем свою чушь сочиняешь?
Я уже говорил, что домен это тупо стандартный тип Firebird с ограничениями, а не новый тип.
Так что твой синтаксис отстой изначально.

rdb_dev
Там же написано, что вся работа с ROWSET может производится только внутри BEGIN..END, а при необходимости "вытащить наружу" (на клиента) надо использовать FOR SELECT..DO SUSPEND внутри BEGIN..END. Ты невнимательно читал.


ну да, и у нас появятся процедуры и функции с параметрами, которые нельзя вызвать с клиента. Круто!
Ну хорошо предположим это можно обойти разрешив их как частные процедуры в рамках Package, но тогда зачем вообще там твой домен, который всегда объявляется в глобальной области.

Я же говорю посмотри как это делается в пакетах Oracle, зачем отсебятину сочинять. Ну хотя бы там продумано всё, а ты и сам не знаешь с какой стороны к своему ROWSET подлезть
21 фев 19, 15:18    [21816492]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Мимопроходящий
а вгде ЭТО может понадобиться?
При передаче записей однородных структур через границы ХП не плодя кучу одинаковых временных таблиц. Что-то типа:
CREATE GLOBAL TEMPORARY TABLE rowset
(
    rowset_id BIGINT NOT NULL,
    id BIGINT NOT NULL PRIMARY KEY,
    name VARCHAR(200) NOT NULL UNIQUE CHARACTER SET UTF8,
  CONSTRAINT rowset__uq UNIQUE (rowset_id, id)
) ON COMMIT PRESERVE ROWS;

CREATE OR ALTER PROCEDURE get
(
  rowset_id BIGINT NOT NULL
)
RETURNS
(
  id BIGINT,
  name VARCHAR(200) NOT NULL UNIQUE CHARACTER SET UTF8
)
AS
BEGIN
  FOR
      SELECT id, name
        FROM rowset
        WHERE rowset_id = :rowset_id
        INTO: id, name
    DO
      SUSPEND;
END;
21 фев 19, 15:24    [21816503]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

для этого можно сделать что-то вроде. Где t1 живёт до конца запроса.

CREATE PACKAGE BODY
AS
  DECLARE LOCAL TEMPORARY TABLE t1(
     id int not null,
     name varchar(100),
     constraint pk1 primary key(id)
  );

  PROCEDURE FILL
  AS 
  BEGIN
     INSERT INTO t1(id, name) VALUE(1, 'Привет');
  END

  PROCEDURE GET_T1 RETURNS (id int, name varchar(100))
  AS
  BEGIN
     EXECUTE PRCOEDURE FILL;
     FOR SELECT id, name
            FROM T1
     INTO id, name
     DO SUSPEND;
  END
END


чем твоя фигня лучше?
21 фев 19, 15:32    [21816513]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис
ну да, и у нас появятся процедуры и функции с параметрами, которые нельзя вызвать с клиента. Круто!
Ну хорошо предположим это можно обойти разрешив их как частные процедуры в рамках Package, но тогда зачем вообще там твой домен, который всегда объявляется в глобальной области.
Зачем мне смотреть, как это сделано у Oracle? Разработчики делают форк Oracle'а? Я предложил идею! Пусть разработчикам не нравится эта идея в предложенном виде, они вправе реализовать её так, как им будет удобнее и использовать тот синтаксис, который им покажется более приемлемым. Мне пофиг! Мне захотелось фичу, реализующую сквозную передачу однородных структур данных вместе с индексами через границы SP/EB в любой последовательности (хоть сверху вниз, хоть снизу вверх).
21 фев 19, 15:34    [21816516]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

я против. Лучше мозг включать при проектировании, чтобы не надо было передавать таблицы как параметр
21 фев 19, 15:39    [21816523]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис
rdb_dev,

+ для этого можно сделать что-то вроде. Где t1 живёт до конца запроса.

CREATE PACKAGE BODY
AS
  DECLARE LOCAL TEMPORARY TABLE t1(
     id int not null,
     name varchar(100),
     constraint pk1 primary key(id)
  );

  PROCEDURE FILL
  AS 
  BEGIN
     INSERT INTO t1(id, name) VALUE(1, 'Привет');
  END

  PROCEDURE GET_T1 RETURNS (id int, name varchar(100))
  AS
  BEGIN
     EXECUTE PRCOEDURE FILL;
     FOR SELECT id, name
            FROM T1
     INTO id, name
     DO SUSPEND;
  END
END
чем твоя фигня лучше?
Тем лучше, что ты эту t1 можешь передать через ROWSET_ID как параметр процедуры хоть на вход, хоть на выход без накладных расходов на постоянное копирование.
21 фев 19, 15:43    [21816537]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис
rdb_dev,

я против. Лучше мозг включать при проектировании, чтобы не надо было передавать таблицы как параметр
А если тебе надо динамически формировать однородные временные структуры и скармливать их процедурам в произвольном порядке, ты будешь плодить кучу одинаковых временных таблиц, а потом с лёгкостью в них запутаешься? Я предложил упрощенный вариант с симуляцией на временных таблицах. Отмотай вверх, глянь.
21 фев 19, 15:46    [21816542]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

я ещё раз говорю. Передавать таблицу как параметр бред. Это от неумения проектировать только возникает.
Что конкретно ты пытаешься решить? Или так фича от балды родилась
21 фев 19, 15:47    [21816544]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис, правда, я там криво написал. Так корректнее:
CREATE GLOBAL TEMPORARY TABLE rowset
(
    rowset_id BIGINT NOT NULL,
    id BIGINT NOT NULL,
    name VARCHAR(200) NOT NULL CHARACTER SET UTF8,
  CONSTRAINT rowset__pk PRIMARY KEY (rowset_id, id),
  CONSTRAINT rowset__uq UNIQUE (rowset_id, name)
) ON COMMIT PRESERVE ROWS;

CREATE OR ALTER PROCEDURE get
(
  rowset_id BIGINT NOT NULL
)
RETURNS
(
  id BIGINT,
  name VARCHAR(200) NOT NULL UNIQUE CHARACTER SET UTF8
)
AS
BEGIN
  FOR
      SELECT id, name
        FROM rowset
        WHERE rowset_id = :rowset_id
        INTO: id, name
    DO
      SUSPEND;
END;
но при такой реализации при JOIN'ах придётся всё время тащить поле rowset_id.
21 фев 19, 15:52    [21816550]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

да, это конечно сложно , ну запихни запрос с фильтрацией в CTE и оперируй ей
21 фев 19, 15:55    [21816553]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис, идея возникла из-за использования рекурсий ХП на значительную глубину при том, что набор записей формируется снизу вверх по рекурсии, то есть сначала вызов доходит до самого низа, а потом снизу начинается формирование набора записей, дополняющегося на уровне сверху и так до выхода из рекурсии. При этом, естественно, идёт постоянное копирование SUSPEND'ом одних и тех же записей из одного буфера в другой и говорить об использовании индексов тут не приходится. Тогда как при использовании набора записей в качестве параметров можно было бы и уменьшить накладные расходы и использовать индексы.
21 фев 19, 15:58    [21816556]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис
rdb_dev,

я ещё раз говорю. Передавать таблицу как параметр бред. Это от неумения проектировать только возникает.
Что конкретно ты пытаешься решить? Или так фича от балды родилась
То есть передавать BLOb по BLOB_ID, это не бред, а передавать набор записей по ROWSET_ID, это бред? :\
21 фев 19, 16:01    [21816560]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9710
rdb_dev,

BLOB вполне себе на диске хранится (или временный может в памяти) и не трогается до поры до времени.

Твоя хрень мало того что данные держит, так и ещё и связанные с ней индексы. Что уже совсем не просто удержать в памяти при значительном объёме данных.

Ну и раз уж ты её всё равно объявляешь свой чудо домен с постоянной структурой, то чем это лучше чем обычные GTT?
То что в параметр надо передать? Ну и передавай свой id_rowset (поле GTT) как параметр, не велики затраты.

Короче не морочь разработчикам голову со своей фигнёй тем более применительно к 4.0, у них есть более важные задачи. И так уж релиз подзатянулся.
21 фев 19, 16:15    [21816575]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис, я нигде не упомянул об ограничении в реализации (память/диск). По мне пусть хоть во временных файлах через memmap храняться. Это обычные динамические наборы записей, похожие на временные таблицы, но гораздо более гибкие в использовании и не захламляющие метаданные БД, если таких таблиц с однородной структурой понадобиться не одна и не две.
21 фев 19, 16:21    [21816579]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Симонов Денис
Короче не морочь разработчикам голову со своей фигнёй тем более применительно к 4.0, у них есть более важные задачи. И так уж релиз подзатянулся.
Так я никогда не настаивал на реализации этой фичи в первом мажорном релизе. Пусть в минорном, пусть не в первом минорном...
21 фев 19, 16:24    [21816583]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47897

rdb_dev
При этом, естественно, идёт постоянное копирование SUSPEND'ом одних и тех же записей из
одного буфера в другой и говорить об использовании индексов тут не приходится.

"Чо?" (с)
Индексы-то к чему при "формировании набора записей по рекурсии"?

Posted via ActualForum NNTP Server 1.5

21 фев 19, 16:48    [21816605]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
pastor
Member

Откуда: Калуга
Сообщений: 993
rdb_dev,

зачем все эти пляски?

у меня в базе есть набор временных таблиц (on commit delete rows) для фактов, атрибутов, измерений и агрегатов.

в них впихивается все, что угодно и передается в рамках транзакции все что угодно.

один минус - в 2.5 не подхватываются индексы в пределах одной ХП, приходится делать выборки через execute statement.
21 фев 19, 17:00    [21816617]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2866
Dimitry Sibiryakov
rdb_dev
При этом, естественно, идёт постоянное копирование SUSPEND'ом одних и тех же записей из
одного буфера в другой и говорить об использовании индексов тут не приходится.

"Чо?" (с)
Индексы-то к чему при "формировании набора записей по рекурсии"?
Если ты с помощью определённых правил в рекурсии формируешь некий набор записей из графа, у элементов этого графа, помимо уникальной комбинации полей в соответствии с 3NF, могут быть первичные ключи, которые, впоследствии, нужны для прочих конъюнкций или дизъюнкций объединений наборов строк?
21 фев 19, 21:44    [21816879]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 23 24 25 26 27 [28] 29 30 31 32 .. 36   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить