Запись в таблицу связанную сама с собой

← →
Mishenka (2006-02-16 14:57) [0]

Есть база, в которой одна из таблиц связана сама с собой, по одному из полей (что-то типа дерева). Пытаюсь записать в таблицу первую запись. Все процедуры записи выполняются, а информация в таблицу почему-то не записывается. Я так понимаю дело в том что в таблице не существует записи со значением ключевого поля равным значению в ссылочном поле (тобишь в том которое указывает с какой записью связана данная запись). Что в таком случае лучше указать в ссылочном поле чтобы записать первую запись в таблицу?

← →
_Le_ (2006-02-16 15:06) [1]

нужно разрешить null для поля-ссылки

← →
Mishenka (2006-02-16 15:20) [2]

> _Le_ (16.02.06 15:06) [1]
> нужно разрешить null для поля-ссылки

Там стоит Required=False, или ты что-то другое имел ввиду?

← →
Sergey13 © (2006-02-16 16:05) [3]

>Что в таком случае лучше указать в ссылочном поле чтобы записать первую запись в таблицу?

NULL

← →
_Le_ (2006-02-16 16:05) [4]

Думаю, да (не в курсе особенностей Paradox).
В первой записи в ссылочном поле должен быть null.
Insert Into table1 (id, id_parant) Values (1, null) (здесь могут быть особенности синтаксиса субд)

← →
Desdechado © (2006-02-16 16:11) [5]

можно заставить ссылаться запись на саму себя
id=1,parent_id=1

← →
_Le_ (2006-02-16 16:21) [6]

> Desdechado ©
это если ссылочной целостности нет, констрейнтов всяких, которые сначала проверяют наличие значения, а потом разрешают вставку

← →
Mishenka (2006-02-16 16:22) [7]

> Desdechado © (16.02.06 16:11) [5]
> можно заставить ссылаться запись на саму себя
> id=1,parent_id=1

Так вроде значение в ключевое поле подставляется автоматически методом Post, или можно как-то его задать вручную?

← →
_Le_ (2006-02-16 16:31) [8]

можете показать кусок кода как запись вставляете? и что именно по логике вашей задачи должно находится в ссылочном поле?

← →
Mishenka (2006-02-16 16:37) [9]

Пожалуйста:
tbModuleInfo.Open; tbModuleInfo.Insert; tbModuleInfo.Fields[1].AsInteger := IDModule; tbModuleInfo.Fields[2].AsDateTime := BeginTime; tbModuleInfo.Fields[3].AsDateTime := EndTime; tbModuleInfo.Fields[4].AsBoolean := Automat; tbModuleInfo.Fields[5].AsBoolean := Schedule; tbModuleInfo.Fields[6].AsBoolean := Config; tbModuleInfo.Fields[7].AsInteger := IDOperator; tbModuleInfo.Fields[8].AsString := CodeType; tbModuleInfo.Fields[9].AsBoolean := Parent; if Parent then tbModuleInfo.Fields[10].AsInteger := ParentModuleID tbModuleInfo.Post; IDModuleInfo := tbModuleInfo.Fields[0].AsInteger; tbModuleInfo.Close;

ParentModuleID это ID модуля на который и происходит ссылка.

← →
_Le_ (2006-02-16 17:13) [10]

tbModuleInfo.Close; - а вот здесь мысль? (может вы просто не видите изменений ... мало-ли бывает)
для получения null в сс поле, просто не присваивается значение для tbModuleInfo.Fields[10] (по-моему)

← →
Desdechado © (2006-02-17 12:26) [11]

_Le_ (16.02.06 16:21) [6]
> это если ссылочной целостности нет, констрейнтов всяких
Может, лучше сначала попробовать, потом гипотезы толкать?
Я постоянно так пользуюсь, и ограничения FK у меня стоят в ОБЯЗАТЕЛЬНОМ порядке, причем ВСЕГДА not null, ибо это дает ощутимый выигрыш в использовании индексов и гарантирует, что бред в ссылочное поле не заскочит. Поэтому категоричное
> нужно разрешить null для поля-ссылки
не приемлю.
Правда, все это относится с SQL-серверам, а не Paradox.

← →
Sergey13 © (2006-02-17 12:35) [12]

2[11] Desdechado © (17.02.06 12:26)
>Правда, все это относится с SQL-серверам, а не Paradox.
На Оракле вводить так позволяет, но при "деревянном" запросе выдает ошибку цикличности дерева ORA-01436 CONNECT BY loop in user data

← →
Desdechado © (2006-02-17 12:41) [13]

при CONNECT BY корень можно обработать отдельно принекотором желании

← →
Sergey13 © (2006-02-17 12:52) [14]

2 [13] Desdechado © (17.02.06 12:41)
Как ты его обработаешь, если с него начать надо?

← →
_Le_ (2006-02-17 13:57) [15]

> Desdechado © (17.02.06 12:26) [11]
Вы правы.

← →
Desdechado © (2006-02-17 14:09) [16]

> Как ты его обработаешь, если с него начать надо?
например, так
SELECT obj_id, obj_name, parent_id, LEVEL FROM objnames START WITH obj_id = 14753 CONNECT BY obj_id = PRIOR parent_id AND obj_id <> parent_id ORDER BY LEVEL DESC

← →
Sergey13 © (2006-02-17 14:44) [17]

2[16] Desdechado © (17.02.06 14:09)
Да, так действительно работает. Не знал.

← →
Mishenka (2006-02-20 09:04) [18]

> tbModuleInfo.Close; - а вот здесь мысль? (может вы просто
> не видите изменений ... мало-ли бывает)

Да нет, я проверял. Не меняется ни дата файлов, ни размер ни содержимое :((

← →
Mishenka (2006-02-21 08:53) [19]

Есть какие-нибудь идеи?

← →
Жуков Олег (2006-02-21 10:16) [20]

tbModuleInfo случайно не TClietDataset? А CashedUpdates у него какое?

> START WITH obj_id = 14753

14753 - это что? Корень? Надо помнить все id корней? И при появлении нового изменять запрос? Тогда уж START WITH obj_id = parent_id в этом случае.

> и ограничения FK у меня стоят в ОБЯЗАТЕЛЬНОМ порядке,

полностью согласен

> причем ВСЕГДА not null

ну это все же на любителя

> ибо это дает ощутимый выигрыш в использовании индексов

не вижу выигрыша. Только если в виде

> START WITH obj_id = :Param

или
START WITH obj_id in (1, 167, 175, 294) :) но переписывать всякий раз SQL при появлении нового корня не есть хорошо, имхо. А в виде
START WITH obj_id = parent_id все равно получишь скорее всего full scan таблицы, если только не используешь супер составной индекс, в котором есть все, что нужно.

> и гарантирует, что бред в ссылочное поле не заскочит.

null - это бред?

2 [21] evvcom © (22.02.06 09:36)
> Тогда уж START WITH obj_id = parent_id в этом случае.
Ну дык тогда получишь вывод всей таблицы. А оно надо? Обычно запрашивают одну [под]ветку.

> Есть какие-нибудь идеи?

[1] чем не устраивает?
Только что попробовал paradox таблицу сделал, наложил constraint, в fk-field позволяет писать null без проблем. Чего не выходит-то?

> Ну дык тогда получишь вывод всей таблицы.

Угу.

> А оно надо?

Зависит от задачи.

> Обычно запрашивают одну [под]ветку.

Зависит от задачи. Эту подветку тоже надо из чего-то выбрать. Не писать же конкретные id в запросе или в клиенте.

2[24] evvcom © (22.02.06 09:55)
> Угу.
А че тогда не просто
select * from table
без всяких наворотов. Результаты похожи. 8-)

> Не писать же конкретные id в запросе или в клиенте.
Через параметр конечно кошернее, но и цифирь подставить не велик грех.

> А че тогда не просто
> select * from table
> без всяких наворотов. Результаты похожи. 8-)

:-) Опять же зависит от задачи. Результаты похожи, но не одно и то же. В "деревянных" запросах сортировка имеется также "деревянная", level можно добавить, а также SYS_CONNECT_BY_PATH. Может еще чего забыл? Ладно, это флейм пошел. :)

> но и цифирь подставить не велик грех.

Я как-то на одном собеседовании был. В той системе разработчик ковыряется только с тестовой системой. Ни одному запросу не дают жить на рабочей базе без тщательного тестирования вышестоящим органом. Прикинь, ты туда цифру забьешь, потребуется корень добавить, ты в запрос добавишь еще цифру и опять на тестирование. Да тебя за такую работу уволят на фиг! Несерьезно это. :(
Да и сейчас разгребаем время от времени запросы, писанные одним уволившимся умельцем. Так там одни цифири и сидят. Волосы дыбом встают.

2[26] evvcom © (22.02.06 10:26)
>В "деревянных" запросах сортировка имеется
С которой все равно придется сильно разбираться на клиенте.

>Я как-то на одном собеседовании был...
А, ты вон про что! 8-)
Естественно, писать конкретную цифирь в коде - глупость. Я имел в виду отличие запроса с параметрами и динамически формируемого запроса.

ЗЫ: Ушли мы от авторского вопроса. Предлагаю замять.

> С которой все равно придется сильно разбираться на клиенте.

Да не... Не сильно. Рекурсивная процедура простейшей реализации строк на 15-20. Сильно упрощает задачу LEVEL. Я так меню пользовательское строю.

> Предлагаю замять.

Да. Согласен.
Автор молчит, я [23] ему настрочил, а он ни гу-гу. Вот мы флеймом и занялись :) Все off.

Запись в таблицу связанную сама с собой Найти похожие ветки