Динамические структуры

← →
O.O (2007-04-26 08:38) [0]

Можно ли в хранимых процедурах использовать какие-нибудь динамические структуры аналогичные паскалевским типа:
Type PStruct = ^Struct; Struct = Record Next: PStruct; Value1: string; Value2, Value3: Integer; // и т.д. end;
И соответствующие операторы типа New, Dispose для создания стеков и списков в памяти?

← →
Johnmen © (2007-04-26 09:05) [1]

Может проще и надёжней документацию почитать?

← →
O.O (2007-04-26 09:48) [2]

> Johnmen © (26.04.07 09:05) [1]

Наверно да, но хороший совет по делу очень сильно ускоряет процесс, показывая в какую сторону копать :)

← →
Johnmen © (2007-04-26 10:13) [3]

> но хороший совет по делу очень сильно ускоряет процесс

Безусловно.
Но в данном случае и дела-то нет никакого...

← →
Jan1 (2007-04-26 10:17) [4]

> Можно ли в хранимых процедурах использовать какие-нибудь
> динамические структуры аналогичные паскалевским типа

а зачем? в чем сакральная мысля?

← →
O.O (2007-04-26 10:30) [5]

> Jan1 (26.04.07 10:17) [4]

Некоторые алгоритмы очень легко создать при помощи этих структур, а как это эффективно сделать при помощи только SQL запросов не знаю, хотя конечно не утверждаю что нельзя, потому-что не всё об SQL знаю а о некоторых вещах наверно и не догадываюсь.

← →
O.O (2007-04-26 10:45) [6]

> Johnmen © (26.04.07 10:13) [3]
Но в данном случае и дела-то нет никакого...

А почему никакого, как-то совсем подругому решается? Или я вообще про какие-то глупости спросил?

← →
Jan1 (2007-04-26 10:51) [7]

> а как это эффективно сделать при помощи только SQL запросов
> не знаю, хотя конечно не утверждаю что нельзя, потому-что
> не всё об SQL знаю а о некоторых вещах наверно и не догадываюсь.
>

вот с этого и надо начинать, а именно: "где взять литературу по SQL".
http://www.google.ru/search?sourceid=navclient-ff&ie=UTF-8&rls=GGGL,GGGL:2006-29,GGGL:ru&q=%D0%93%D1%80%D1%83%D0%B1%D0%B5%D1%80+%D0%BF%D0%BE%D0%BD%D0%B8%D0%BC%D0%B0%D0%BD%D0%B8%D0%B5+SQL

← →
O.O (2007-04-26 10:57) [8]

Так значит ответ на вопрос - НЕТ
Всё делается только средствами SQL

← →
Desdechado © (2007-04-26 11:02) [9]

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

ЗЫ Вообще лучше поищи другой способ гонять свои алгоритмы. Потому как замучаешь свой сервер (а он - тебя) сборкой мусора.

← →
Val © (2007-04-26 11:15) [10]

offtop: они вроде в 2.1 temporary tables обещали... - появились?

← →
Jan1 (2007-04-26 11:18) [11]

> offtop: они вроде в 2.1 temporary tables обещали... - появились?

http://www.firebirdsql.org/devel/doc/rlsnotes/html/rlsnotes21.html#rnfb21a-new-obj

← →
Jan1 (2007-04-26 11:18) [12]

> offtop: они вроде в 2.1 temporary tables обещали... - появились?

http://www.firebirdsql.org/devel/doc/rlsnotes/html/rlsnotes21.html#rnfb21a-new-obj

← →
Val © (2007-04-26 11:23) [13]

спасибо.
ну тогда вот и пожалуйста - желаемые автором динамические структуры.

← →
O.O (2007-04-26 11:50) [14]

Я вот как раз и не хочу создавать временных таблиц, потому как врядли это эффективный путь решения. Может лучше обьясню в кратце проблему:
Одна таблица с первичными записями. В её составе нас интерисуют два поля:
KOD - первичный индекс.
LEVEL - уровень вложения, т.е. любая запись этой таблицы как-бы состоит из набора записей этой-же таблицы, и это поле отражает глубину вложенности.
Вторая таблица описывает структуру записей первой таблицы. Для управления вложенностью записей два поля:
MASTER_KOD - Ссылка на поле KOD первой таблицы (корневая запись структуры)
SLAVE_KOD - Сылка на поле KOD первой таблицы (составляющая структуры).
Отношения между таблицами - один ко многим по полям KOD/MASTER_KOD и соответственно один к одному по полям SLAVE_KOD/KOD. Остальные поля таблицы для создания алгоритма значения не имеют.

Нужно сделать следующее:
1. По полю KOD первой таблицы получить все составляющие из этой-же таблицы, т.е. развернуть её до элементов с нулевыми уровнями вложенности.
3. Вычислять уровень вложенности
2. Во время создания структуры следить чтоб не возникло циклических ссылок.
Как это делать при помощи SQL без временных таблиц ума не приложу. Легко это сделал в Delphi, однако во время разворачивания структуры для разворачивания каждой сложной составляющей создаётся новый запрос, пока вся структура не развернётся до элементарных составляющих. Через сеть думаю это делать неразумно. Вот вобщем-то и всё.

← →
O.O (2007-04-26 11:55) [15]

Да кстати, сделать это с рекурсией получается, но где-то читал что FireBird делает ограничение до 1000 и после этого выдаёт ошибку. Напороться на это где-нибудь в будующем, когда количество данных будет увеличиваться хочется не очень.

← →
Jan1 (2007-04-26 12:08) [16]

читать: http://ibase.ru/develop.htm - Древовидные и иерархические структуры, хранение объектов

← →
O.O (2007-04-26 12:13) [17]

> Jan1 (26.04.07 11:18) [12]

А как ентим пользоваться?

← →
O.O (2007-04-26 12:17) [18]

> Jan1 (26.04.07 12:08) [16]
> читать: http://ibase.ru/develop.htm - Древовидные и иерархические
> структуры, хранение объектов

Спасибо, буду читать :)

← →
O.O (2007-04-26 12:24) [19]

Очень хороший материал, как раз то что нужно :)
Ещё раз спасибочки !

← →
Desdechado © (2007-04-26 12:55) [20]

> с рекурсией получается, но где-то читал что FireBird делает ограничение до 1000
И каким боком ты такую вложенность будешь организовывать? Кому она может понадобиться? И зачем нужны выборки, из многих тысяч элементов?

← →
Сергей М. © (2007-04-26 13:39) [21]

> O.O (26.04.07 08:38)

> Можно ли в хранимых процедурах использовать какие-нибудь
> динамические структуры

Можно.
см. IB UDF

← →
Desdechado © (2007-04-26 13:55) [22]

> см. IB UDF
А толку? Для задачи O.O (26.04.07 11:50) [14] бессмысленно и, имхо, невозможно.

← →
O.O (2007-04-26 14:32) [23]

> Сергей М. © (26.04.07 13:39) [21]

Обязательно посмотрю.

> Desdechado © (26.04.07 13:55) [22]
> > см. IB UDF
> А толку? Для задачи O.O (26.04.07 11:50) [14] бессмысленно
> и, имхо, невозможно.

Если действительно такое есть то почему невозможно? Я же писал в [5] что всё уже прекрасно работает в DELPHI, да и какие там могут быть сложности?

← →
Jan1 (2007-04-26 14:56) [24]

> Если действительно такое есть то почему невозможно? Я же
> писал в [5] что всё уже прекрасно работает в DELPHI, да
> и какие там могут быть сложности?

SQL - это язык манипулирования данными а не ссылками и указателями. Вот в чем сложность. Соответственно и подход другой к решению задач.
Это как гол, в хоккее это делается одним способом, в футболе другим, но результат тот же.

← →
Desdechado © (2007-04-26 15:36) [25]

> Если действительно такое есть то почему невозможно?
Для начала рекомендую ознакомиться с теорией UDF, а потом возмущаться.

ЗЫ UDF ориентированы на БЫСТРОЕ выполнение КОРОТКИХ операций, которые не привязаны к SQL. Например, взятие тангенса, перепаковка блоба и т.п. Т.е. никакого обращения к набору данных там быть не может. Уж тем более построения иерархий по таблицам.

← →
Сергей М. © (2007-04-26 15:44) [26]

> Desdechado © (26.04.07 13:55) [22]

Я всего лишь в точности ответил на точно поставленный вопрос.

Вопрос-то был "можно ли ... использовать")
Я и ответил, что можно, и, надеюсь, с твоей стороны возражений не будет)
Ну а "толк" - это из другой оперы)

> [14] O.O (26.04.07 11:50)
> соответственно один к одному по полям SLAVE_KOD/KOD

зачем тогда вторая таблица? Добавь в первую master_kod (обычно обзывают parent) и все дела. Вторая таблица нужна когда сущность может входить в разные ветки дерева.

← →
O.O (2007-04-26 16:43) [28]

> зачем тогда вторая таблица? Добавь в первую master_kod (обычно
> обзывают parent) и все дела. Вторая таблица нужна когда
> сущность может входить в разные ветки дерева.

Так оно так и есть. Сначала создаётся запись в первой таблице. Она с нулевым уровнем. Затем запись можно усложнить, добавив в её состав другие записи из этой-же таблицы, они тоже могут быть составными. Состав фиксируем во второй таблице и не позволяем загонять в неё составляющие в состав которых входит наша формируемая запись (здесь впервые и применяем равёртывание входящего на атомы). Структура не очень "деревянная", но близкая, или я что-то до сих пор не понимаю.

> [28] O.O (26.04.07 16:43)

Что-то я запутался. Если к примеру взять файловую систему (умозрительную). Может входить ОДИН файл (НЕ КОПИЯ) в разные директории по твоей схеме?

← →
O.O (2007-04-26 17:56) [30]

Ещё один пример.
Для большей ясности введём во вторую таблицу ещё пару полей, и так:
Т1 - KOD, LEVEL
T2 - KOD, MASTER_KOD, SLAVE_KOD, KOL_VO
Ограничемся этим хотя параметров побольше, но они непосредственно на алгоритм структуры не влияют, как не влияют добавленные поля, а только на расчёты и другие действия.
Вносим в Т1 элементарные записи 1; 0 2; 0 3; 0 4; 0
Усложняем структуру записи Т1 KOD = 3 вписав в Т2 следующее: 1; 3; 1; 10 2; 3; 2; 10
И изменяем уровень Т1 KOD = 3 3; 1
Усложняем структуру записи Т1 KOD = 4 вписав в Т2 следующее: 3; 4; 1; 20 4; 4; 2; 15 И изменяем уровень Т1 KOD = 4 4; 1 Вносим в Т1 элементарные записи 5; 0 6; 0 Усложняем структуру записи Т1 KOD = 5 вписав в Т2 следующее: 5; 5; 1; 10 6; 5; 3; 5 7; 5; 6; 10 И изменяем уровень Т1 KOD = 5 3; 2 И т.д. Видим следующее: - Структуры Т1 KOD=3 и T1 KOD=4 одинаковы однако они не тождественны. - В структуру записи Т1 KOD = 5 входит Т1 KOD = 1 дважды, непосредственно как Т1 KOD = 1 и опосредовано через T1 KOD = 3, и вообще заранее мы не знаем какие структуры попытаются сразу внести в список состава или какие добавят или удалят в дальнейшем, главное не допустить циклических ссылок. В дальнейшем мы можем добавить или удалить какие либо составляющие в любую запись Т1 и посредством этого усложнить или упростить записи в состав которых они входят. Как-то так :)

← →
O.O (2007-04-26 17:57) [31]

Запутался в тегах в торопях :)

> [30] O.O (26.04.07 17:56)

Вместо этого я ждал всего одной фразы - ЗАПИСЬ С ОДНИМ КОДОМ МОЖЕТ ИМЕТЬ НЕСКОЛЬКО РОДИТЕЛЬСКИХ.
Если так, я свое замечание снимаю.
Не очень понятен смысл LEVEL, но может я просто не вник.

← →
O.O (2007-04-27 11:13) [33]

LEVEL для отображения в гриде

← →
O.O (2007-04-27 11:15) [34]

Имеется ввиду отображения уровня вложенности объекта, ну или глубины

> [34] O.O (27.04.07 11:15)

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

> Имеется ввиду отображения уровня вложенности объекта, ну
> или глубины

Да, но если объект может иметь НЕСКОЛЬКО родителей (а именно для этого нужна таблица T2), то об одном LEVEL у объекта из таблицы T1 не может быть и речи.
Как и KOL_VO. Это количество слайвов для мастера или мастеров для сэйва? Да и зачем хранить то, что можно посчитать?

← →
O.O (2007-04-27 11:33) [37]

Выборку хорошую с расчётом вложений пока не придумал, разбираюсь в предложенном для чтения Jan1 (26.04.07 12:08) [16] :)
Да и число это чисто информативное, чтобы пользователь имел ввиду приблизительно до чего довёл объект.

← →
O.O (2007-04-27 12:21) [38]

> ЮЮ © (27.04.07 11:30) [36]
> > Имеется ввиду отображения уровня вложенности объекта,
> ну
> > или глубины
>
>
> Да, но если объект может иметь НЕСКОЛЬКО родителей (а именно
> для этого нужна таблица T2), то об одном LEVEL у объекта
> из таблицы T1 не может быть и речи.

Считаю просто максимальный LEVEL среди родителей + 1.

Динамические структуры Найти похожие ветки