Форум: "Начинающим";
Текущий архив: 2006.03.26;
Скачать: [xml.tar.bz2];
ВнизInterbase. Пусто поле.... Найти похожие ветки
← →
VitV © (2006-03-13 18:26) [0]Поле типа integer.Возможно ли сделать так, чтобы там было значение,а в другом случае поле оставалось пустое. или лучше записывать туда 0?
← →
Ega23 © (2006-03-13 18:27) [1]NULL для этого существует.
← →
Sergey13 © (2006-03-14 09:21) [2]2VitV © (13.03.06 18:26)
Теоретически, от NULL лучше избавляться. Но в реальной жизни это не всегда возможно и оправдано.
← →
Ega23 © (2006-03-14 09:23) [3]
> Теоретически, от NULL лучше избавляться. Но в реальной жизни
> это не всегда возможно и оправдано.
Деревянная таблица, ParentID корневой записи... :о)
Чесно говоря, больше нигде, кроме BLOB, не использую
← →
Sergey13 © (2006-03-14 09:34) [4]2[3] Ega23 © (14.03.06 09:23)
>Деревянная таблица, ParentID корневой записи... :о)
Недавно про это спорили и мне доказали, что он может и не быть NULL-ом. 8-)
← →
msguns © (2006-03-14 09:45) [5]>Sergey13 © (14.03.06 09:34) [4]
>Недавно про это спорили и мне доказали, что он может и не быть NULL-ом.
Легко
← →
Ega23 © (2006-03-14 09:56) [6]
> Недавно про это спорили и мне доказали, что он может и не
> быть NULL-ом. 8-)
А как? Я как-то что-то подобное сумел сотворить, но, честно говоря, уже не помню как...
← →
Sergey13 © (2006-03-14 10:00) [7]2[6] Ega23 © (14.03.06 09:56)
Например ParentID может быть равен ID - чем не условие.
Или (это я давно знал, но не применял никогда), можно завести "самую корневую" запись (с фиксированным ID-шником) и всем "простым" корням ссылаться на нее.
← →
Ega23 © (2006-03-14 10:05) [8]
> можно завести "самую корневую" запись (с фиксированным ID-
> шником)
И какой ParentID будет у этой "самой корневой записи"?
На самом деле мне этот вариант не нравится тем, что добавляется одно лишнее условие при рекурсивных выборках (and ID>Самый_Корневой_ID)
← →
Sergey13 © (2006-03-14 10:11) [9]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:22) [10]
> Или =ID или NULL. Но NULL тут уже не "страшен",
Ну вот если равно ID, и если не поставишь условие на выборку, чтобы без этой записи, то попадёшь в бесконечную рекурсию.
А если NULL - то мы пришли к тому, с чего начинали, т.к. у меня и так всегда одна коневая запись... :о)
← →
Sergey13 © (2006-03-14 10:32) [11]2[10] Ega23 © (14.03.06 10:22)
Это если подниматься от ветки к корню? Ну да. Но на НУЛЛ то ты проверяешь все равно, почему на ParentID=0 не проверить?
← →
Ega23 © (2006-03-14 10:45) [12]
> Это если подниматься от ветки к корню?
Нет, это как раз тривиально, никаких курсоров не надо, всё через while построить можно.
А вот выбор потомков от какого-то узла (в самом тяжёлом случае - от корня) ...
← →
Sergey13 © (2006-03-14 10:52) [13]2[12] Ega23 © (14.03.06 10:45)
> А вот выбор потомков от какого-то узла (в самом тяжёлом случае - от корня) ...
Ну дык начинать или от ParentID=0 (в случае с суперкорнем) или от ParentID=ID.
С выбором потомков вообще (с этой точки зрения) проблем нет, ибо начинаешь как правило с конкретного ID.
Я к чему сюда встрял то? К тому, что при where FIELD is NULL индексы не работают. Отсюда и теоретическое желание избавления от NULL.
← →
Ega23 © (2006-03-14 11:20) [14]
> Я к чему сюда встрял то? К тому, что при where FIELD is
> NULL индексы не работают.
Честно говоря, не очень представляю себе создание индекса на иерархической таблице...
← →
msguns © (2006-03-14 11:24) [15]>Ega23 © (14.03.06 10:05) [8]
>На самом деле мне этот вариант не нравится тем, что добавляется одно лишнее условие при рекурсивных выборках
С какого такого бодуна ?
Рекурсия идет внутри "раскрутки", которая начинаяется с элемента ветви i-го уровня (в простейшем случае - с "корневого" узла). Для получения полного дерева в ХП выбираются сначала все "корни" и в цикле для каждого выплняется другая ХП, в которой собсна и рекурсия.
Для выбора "корней" годится любое: хоть нул, хоть -1, хоть 0
← →
Sergey13 © (2006-03-14 11:31) [16]2[14] Ega23 © (14.03.06 11:20)
> Честно говоря, не очень представляю себе создание индекса на иерархической таблице...
Во первых, про иерархию ты начал. 8-) Сначала про нее речи не было.
Во вторых, почему? ID и ParentID в одном индексе должны споспешествовать, ИМХО.
← →
Ega23 © (2006-03-14 11:34) [17]
> Для получения полного дерева в ХП выбираются сначала все
> "корни" и в цикле для каждого выплняется другая ХП, в которой
> собсна и рекурсия.
Есть таблица
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:36) [18]2 [17] Ega23 © (14.03.06 11:34)
> Если устроить выбор всего от корня,
А зачем от него начинать, если знаешь, что это псевдокорень?
← →
Ega23 © (2006-03-14 11:39) [19]Хорошо. Предположим, что корень - FirstClass и SecondClass. Как в таком случае должна выглядеть выборка? Ведь всё равно придётся псевдокорень исключать. А это и есть то самое лишнее условие, про которое я изначально говорил.
← →
msguns © (2006-03-14 11:49) [20]Все же я не пойму о чем сыр-бор. Если у тебя инкремент начинается с 0 (у меня завсегда с 1), то "лепи" корешкам -1 в парентский ид. И проверяй при определении "корешков"
where parentID<1
← →
msguns © (2006-03-14 11:49) [21]пардон, <0 есно
← →
Sergey13 © (2006-03-14 11:52) [22]2[19] Ega23 © (14.03.06 11:39)
>Ведь всё равно придётся псевдокорень исключать.
Ты предлагаешь исключать, а я предлагаю выбирать нормальные (действительные) корни. Тут и разница. При начальном запросе как в [9] Sergey13 © (14.03.06 10:11) пофиг этот псевдокорень и чему он равен. NULL в запросе нет и индекс соответственно работает.
Или я запутался уже. 8-)
← →
Ega23 © (2006-03-14 12:00) [23]А. Я понял о чём вы.
Вся проблема в том, что я constraint ставлю, ParentID есть вторичный ключ по отношению к ID. И так без NULL - очень тяжело обойтись.
← →
Sergey13 © (2006-03-14 12:03) [24]2[23] Ega23 © (14.03.06 12:00)
>Вся проблема в том, что я constraint ставлю
И я без этого ни-ни. 8-)
← →
msguns © (2006-03-14 12:08) [25]>Ega23 © (14.03.06 12:00) [23]
>Вся проблема в том, что я constraint ставлю, ParentID есть вторичный ключ по отношению к ID.
Ну и что ? А причем тут NULL ?
← →
Fay © (2006-03-14 12:09) [26]2 Sergey13 © (14.03.06 9:21) [2]
> Теоретически, от NULL лучше избавляться
Это что за теория такая? Кислых щей?
← →
Desdechado © (2006-03-14 12:14) [27]автору
Если поле индексируемое и по нему идут поиски-соединения таблиц, то пиши некоторое псевдопустое значение (величину его сам выбери).
Если поле - простой атрибут, который только "для кучи" в таблицу положен,то можешь смело NULL кидать.
спорящим
Я предпочитаю для деревьев (ибо там всегда ключи ииндексы) для корня писать id=parent_id. Это прекрасно отрабатывает, как уже сказал Sergey13 © (14.03.06 09:34) [4]. Для Оракла я ему и запрос демонстрировал. Для IB запросом не обойдешься, ХП нужна, но тоже удобно получается.
← →
Sergey13 © (2006-03-14 12:15) [28]2[26] Fay © (14.03.06 12:09)
Может и в кулинарии такое есть. Не знаю. Тут тебе карты в руки.
← →
msguns © (2006-03-14 12:23) [29]>Desdechado © (14.03.06 12:14) [27]
>для корня писать id=parent_id.
Есть и такое решение. Кстати, не самое плохое ;)
← →
Sergey13 © (2006-03-14 12:23) [30]2[27] Desdechado © (14.03.06 12:14)
>Если поле - простой атрибут, который только "для кучи" в таблицу положен,то можешь смело NULL кидать.
Тоже не всегда. Например если в числах стоит NULL, то надо часто отдельно это обрабатывать.
← →
Fay © (2006-03-14 12:26) [31]2 Sergey13 © (14.03.06 12:15) [28]
Ну так что за теория такая? Какие аргументы против null, кроме "Может" и "Не знаю"?
← →
Sergey13 © (2006-03-14 12:27) [32]2 [31] Fay © (14.03.06 12:26)
А какой аргумент ЗА "неопределено"?
← →
Fay © (2006-03-14 12:31) [33]2 Sergey13 © (14.03.06 12:27) [32]
> А какой аргумент ЗА "неопределено"?
Вместо ответов пошли встречные вопросы. Мне всё понятно.
← →
Sergey13 © (2006-03-14 12:49) [34]2[33] Fay © (14.03.06 12:31)
Если ты не прочитал предыдущие 30 постов, мне заново все повторять?
← →
Fay © (2006-03-14 12:51) [35]2 Sergey13 © (14.03.06 12:49) [34]
Во-первых, я прочитал. Во-вторых, там нет ни одного аргумента против NULL. К тому же прочему ответ [2] был написан вне контекста остальных постов.
← →
Fay © (2006-03-14 12:54) [36]Что означает слово "прочему" я не знаю. Как появилось в моём ответе - тоже 8)
← →
Sergey13 © (2006-03-14 12:55) [37]2 [35] Fay © (14.03.06 12:51)
1. NULL не индексируется.
2. NULL должен часто обрабатываться отличными от "стандартных" способами и вообще отдельно от "определенных" данных.
Про все это выше писАлось. Этого недостаточно?
← →
Desdechado © (2006-03-14 12:59) [38]За NULL:
1. не занимает места
Против NULL:
1. не индексируется напрямую (со всемы вытекающими)
2. требует дополнительной обработки в проверках (n=3 OR n is null)
← →
Fay © (2006-03-14 13:01) [39]2 Sergey13 © (14.03.06 12:55) [37]
> Этого недостаточно
Это просто свойства NULL.
← →
Sergey13 © (2006-03-14 13:03) [40]2[39] Fay © (14.03.06 13:01)
> Это просто свойства NULL.
Полезные?
Страницы: 1 2 вся ветка
Форум: "Начинающим";
Текущий архив: 2006.03.26;
Скачать: [xml.tar.bz2];
Память: 0.55 MB
Время: 0.061 c