![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Interbase. Пусто поле.... [D7, XP]
VitV © (2006-03-13 18:26:00)Поле типа integer.Возможно ли сделать так, чтобы там было значение,а в другом случае поле оставалось пустое. или лучше записывать туда 0?
Desdechado (2006-03-14 12:14:00) [21]автору
Если поле индексируемое и по нему идут поиски-соединения таблиц, то пиши некоторое псевдопустое значение (величину его сам выбери).
Если поле - простой атрибут, который только "для кучи" в таблицу положен,то можешь смело NULL кидать.
спорящим
Я предпочитаю для деревьев (ибо там всегда ключи ииндексы) для корня писать id=parent_id. Это прекрасно отрабатывает, как уже сказал Sergey13 © (14.03.06 09:34) [4]. Для Оракла я ему и запрос демонстрировал. Для IB запросом не обойдешься, ХП нужна, но тоже удобно получается.
Fay (2006-03-14 12:09:00) [22]2 Sergey13 © (14.03.06 9:21) [2]
> Теоретически, от NULL лучше избавляться
Это что за теория такая? Кислых щей?
msguns (2006-03-14 12:08:00) [23]>Ega23 © (14.03.06 12:00) [23]
>Вся проблема в том, что я constraint ставлю, ParentID есть вторичный ключ по отношению к ID.
Ну и что ? А причем тут NULL ?
Sergey13 (2006-03-14 12:03:00) [24]2[23] Ega23 © (14.03.06 12:00)
>Вся проблема в том, что я constraint ставлю
И я без этого ни-ни. 8-)
Ega23 (2006-03-14 12:00:00) [25]А. Я понял о чём вы.
Вся проблема в том, что я constraint ставлю, ParentID есть вторичный ключ по отношению к ID. И так без NULL - очень тяжело обойтись.
Sergey13 (2006-03-14 11:52:00) [26]2[19] Ega23 © (14.03.06 11:39)
>Ведь всё равно придётся псевдокорень исключать.
Ты предлагаешь исключать, а я предлагаю выбирать нормальные (действительные) корни. Тут и разница. При начальном запросе как в [9] Sergey13 © (14.03.06 10:11) пофиг этот псевдокорень и чему он равен. NULL в запросе нет и индекс соответственно работает.
Или я запутался уже. 8-)
msguns (2006-03-14 11:49:00) [27]пардон, <0 есно
msguns (2006-03-14 11:49:00) [28]Все же я не пойму о чем сыр-бор. Если у тебя инкремент начинается с 0 (у меня завсегда с 1), то "лепи" корешкам -1 в парентский ид. И проверяй при определении "корешков"
where parentID<1
Ega23 (2006-03-14 11:39:00) [29]Хорошо. Предположим, что корень - FirstClass и SecondClass. Как в таком случае должна выглядеть выборка? Ведь всё равно придётся псевдокорень исключать. А это и есть то самое лишнее условие, про которое я изначально говорил.
Sergey13 (2006-03-14 11:36:00) [30]2 [17] Ega23 © (14.03.06 11:34)
> Если устроить выбор всего от корня,
А зачем от него начинать, если знаешь, что это псевдокорень?
Ega23 (2006-03-14 11:34:00) [31]
> Для получения полного дерева в ХП выбираются сначала все
> "корни" и в цикле для каждого выплняется другая ХП, в которой
> собсна и рекурсия.
Есть таблица
id pid Name
0 0 root
1 0 FirstNode
2 0 SecondNode
3 1 ThirdNode
.......
Если устроить выбор всего от корня, то если в выборе where pid=id (при рекурсивном обходе) на первом шаге не добавить and id>0, то мы на записи root уйдём в бесконечную рекурсию.
Sergey13 (2006-03-14 11:31:00) [32]2[14] Ega23 © (14.03.06 11:20)
> Честно говоря, не очень представляю себе создание индекса на иерархической таблице...
Во первых, про иерархию ты начал. 8-) Сначала про нее речи не было.
Во вторых, почему? ID и ParentID в одном индексе должны споспешествовать, ИМХО.
msguns (2006-03-14 11:24:00) [33]>Ega23 © (14.03.06 10:05) [8]
>На самом деле мне этот вариант не нравится тем, что добавляется одно лишнее условие при рекурсивных выборках
С какого такого бодуна ?
Рекурсия идет внутри "раскрутки", которая начинаяется с элемента ветви i-го уровня (в простейшем случае - с "корневого" узла). Для получения полного дерева в ХП выбираются сначала все "корни" и в цикле для каждого выплняется другая ХП, в которой собсна и рекурсия.
Для выбора "корней" годится любое: хоть нул, хоть -1, хоть 0
Ega23 (2006-03-14 11:20:00) [34]
> Я к чему сюда встрял то? К тому, что при where FIELD is
> NULL индексы не работают.
Честно говоря, не очень представляю себе создание индекса на иерархической таблице...
Sergey13 (2006-03-14 10:52:00) [35]2[12] Ega23 © (14.03.06 10:45)
> А вот выбор потомков от какого-то узла (в самом тяжёлом случае - от корня) ...
Ну дык начинать или от ParentID=0 (в случае с суперкорнем) или от ParentID=ID.
С выбором потомков вообще (с этой точки зрения) проблем нет, ибо начинаешь как правило с конкретного ID.
Я к чему сюда встрял то? К тому, что при where FIELD is NULL индексы не работают. Отсюда и теоретическое желание избавления от NULL.
Ega23 (2006-03-14 10:45:00) [36]
> Это если подниматься от ветки к корню?
Нет, это как раз тривиально, никаких курсоров не надо, всё через while построить можно.
А вот выбор потомков от какого-то узла (в самом тяжёлом случае - от корня) ...
Sergey13 (2006-03-14 10:32:00) [37]2[10] Ega23 © (14.03.06 10:22)
Это если подниматься от ветки к корню? Ну да. Но на НУЛЛ то ты проверяешь все равно, почему на ParentID=0 не проверить?
Ega23 (2006-03-14 10:22:00) [38]
> Или =ID или NULL. Но NULL тут уже не "страшен",
Ну вот если равно ID, и если не поставишь условие на выборку, чтобы без этой записи, то попадёшь в бесконечную рекурсию.
А если NULL - то мы пришли к тому, с чего начинали, т.к. у меня и так всегда одна коневая запись... :о)
Sergey13 (2006-03-14 10:11:00) [39]2[8] Ega23 © (14.03.06 10:05)
> И какой ParentID будет у этой "самой корневой записи"?
Или =ID или NULL. Но NULL тут уже не "страшен", т.к. это будет всего 1 запись в таблице и она никогда не будет встречаться в запросах
Все корни
Select * from tree_table where ParentID=0
Ega23 (2006-03-14 10:05:00) [40]
> можно завести "самую корневую" запись (с фиксированным ID-
> шником)
И какой ParentID будет у этой "самой корневой записи"?
На самом деле мне этот вариант не нравится тем, что добавляется одно лишнее условие при рекурсивных выборках (and ID>Самый_Корневой_ID)