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]
> А какой аргумент ЗА "неопределено"?
Вместо ответов пошли встречные вопросы. Мне всё понятно.

2 Sergey13 © (14.03.06 12:49) [34]
Во-первых, я прочитал. Во-вторых, там нет ни одного аргумента против NULL. К тому же прочему ответ [2] был написан вне контекста остальных постов.

Что означает слово "прочему" я не знаю. Как появилось в моём ответе - тоже 8)

2 [35] Fay © (14.03.06 12:51)
1. NULL не индексируется.
2. NULL должен часто обрабатываться отличными от "стандартных" способами и вообще отдельно от "определенных" данных.

Про все это выше писАлось. Этого недостаточно?

За NULL:
1. не занимает места

Против NULL:
1. не индексируется напрямую (со всемы вытекающими)
2. требует дополнительной обработки в проверках (n=3 OR n is null)

2 Sergey13 © (14.03.06 13:03) [40]
> Полезные?
Ну что за хрень? Как, по-твоему, задать пустую дату? Просто для примера...

> Как, по-твоему, задать пустую дату?
Зависит от того, что решает система, от ее допустимого диапазона дат,от того, как они обрабатываются.
Я, например, довольно часто использую "0001-01-01 00:00:00"

2[41] Fay © (14.03.06 13:05)
> Как, по-твоему, задать пустую дату?
А как ее потом корректно распечатать (например), специально не обрабатывая эту ситуацию?
Никто не говорит, что NULL - это отстой и его нельзя использовать. Но сокращать его использование - правильный путь. ИМХО.

Что значит сокращать? NULL должен быть там, где должен (во как!) и больше нигде. В случае с ParentID нет никакой необходимости использовать NULL, но таких случаев много не наберётся.
Пример:
> Я, например, довольно часто использую "0001-01-01 00:00:00" ( © Desdechado )
Как здесь понимать результат выборки вида where my_date < now() ?

> А как ее потом корректно распечатать
Проблема явно высосана из пальца.

2[44] Fay © (14.03.06 13:31)
>Что значит сокращать? NULL должен быть там, где должен (во как!) и больше нигде.
Скорее так - там, где без него никак иначе. В идеале конечно. ИМХО.

> Проблема явно высосана из пальца.
Как и проблема с вводом "пустой" даты. 8-)

> Как здесь понимать результат выборки вида where my_date < now() ?
Не понял в чем вопрос. Но на всякий случай повторю: Зависит от того, что решает система, от ее допустимого диапазона дат,от того, как они обрабатываются.

2 Desdechado © (14.03.06 13:51) [46]
> Но на всякий случай повторю
Я и с первого раза понял. Но почему бы не вспомнить, что очень не всегда нужна с условием по полям с NULL?

Interbase. Пусто поле.... Найти похожие ветки