Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Динамические структуры [D6, FB 2.0]

Страницы: 1 2 >
O.O © (2007-04-26 08:38:00)
Можно ли в хранимых процедурах использовать какие-нибудь динамические структуры аналогичные паскалевским типа:
Type PStruct = ^Struct; Struct = Record Next: PStruct; Value1: string; Value2, Value3: Integer; // и т.д. end;
И соответствующие операторы типа New, Disposeдля создания стеков и списков в памяти?

O.O (2007-04-27 12:21:00) [1]

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

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

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

ЮЮ (2007-04-27 11:30:00) [3]
> Имеется ввиду отображения уровня вложенности объекта, ну
> или глубины

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

Sergey13 (2007-04-27 11:21:00) [4]
> [34] O.O (27.04.07 11:15)

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

O.O (2007-04-27 11:15:00) [5]
Имеется ввиду отображения уровня вложенности объекта, ну или глубины

O.O (2007-04-27 11:13:00) [6]
LEVEL для отображения в гриде

Sergey13 (2007-04-27 09:25:00) [7]
> [30] O.O (26.04.07 17:56)

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

O.O (2007-04-26 17:57:00) [8]
Запутался в тегах в торопях :)

O.O (2007-04-26 17:56:00) [9]
Ещё один пример.
Для большей ясности введём во вторую таблицу ещё пару полей, и так:
Т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 и посредством этого усложнить или упростить записи в состав которых они входят. Как-то так :)

Sergey13 (2007-04-26 16:50:00) [10]
> [28] O.O (26.04.07 16:43)

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

O.O (2007-04-26 16:43:00) [11]

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

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

Sergey13 (2007-04-26 16:17:00) [12]
> [14] O.O (26.04.07 11:50)
> соответственно один к одному по полям SLAVE_KOD/KOD

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

Сергей М. (2007-04-26 15:44:00) [13]

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

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

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

Desdechado (2007-04-26 15:36:00) [14]
> Если действительно такое есть то почему невозможно?
Для начала рекомендую ознакомиться с теорией UDF, а потом возмущаться.

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

Jan1 (2007-04-26 14:56:00) [15]

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

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

O.O (2007-04-26 14:32:00) [16]

> Сергей М. © (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, да и какие там могут быть сложности?

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

Сергей М. (2007-04-26 13:39:00) [18]

> O.O (26.04.07 08:38)

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

Можно.
см. IB UDF

Desdechado (2007-04-26 12:55:00) [19]
> с рекурсией получается, но где-то читал что FireBird делает ограничение до 1000
И каким боком ты такую вложенность будешь организовывать? Кому она может понадобиться? И зачем нужны выборки, из многих тысяч элементов?

O.O (2007-04-26 12:24:00) [20]
Очень хороший материал, как раз то что нужно :)
Ещё раз спасибочки !

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »