Стратегия пустых полей

← →
Kostafey © (2009-02-19 11:34) [0]

Давно думаю как правильно следует делать.

Допустим у нас есть некая база с таблицами.
Одна основная, другая справочник, привязанная к первой.

Допустим пользователь заполняет основную таблицу, он может
выбрать одно из значений справочной таблицы. А может
и не выбрать.

Для случая, когда он не выбрал можно оставлять поле null,
можно привязывать все же некоторый идентификатор справочника,
например, содержащий значение "не указано" (или что-то в этом роде).

Как правильнее делать?

← →
clickmaker © (2009-02-19 11:39) [1]

если нужна будет локализация, то, возможно, имеет смысл, поскольку "не указано" может быть на нескольких языках.
если там будет некий ID, то логика определения не указанных значений должна быть завязана именно на проверку этого значения, а не is null, что может быть неудобно / не очевидно.

← →
Ega23 © (2009-02-19 11:40) [2]

> Как правильнее делать?

Однозначного ответа нет.
Оба подхода имеют право на жизнь.
Лично я стараюсь на FK всегда NOT NULL накладывать. Исключение - иерархические таблицы с FK на саму себя.
Ну и первая запись - типа "Нет" или "Отсутствует" или ещё что-то...

← →
Kinda (2009-02-19 11:40) [3]

Думаю что и так и так можно, на мне всеж больше по душе присвоение значения "не указано", по нескольким причинам:
1. На справочник можно сделать внешний ключ.
2. Меньше возни потом с обработкой нуллов в запросах.

← →
Kostafey © (2009-02-19 11:49) [4]

Могу привести еще один пример полезности записи "не указано".

Допустим, задача тербует, чтобы при работе пользователь обязательно
выбрал одно из значений, но не просто оставил значение в списке по
умолчанию, а открыл список и выбрал значение. Тогда значение по умолчанию
не должно выбираться вообще, но в списке присутствовать должно,
притом первым пунктом.

Я сначала думал, что добавлять для этого запись в таблицу справочника
слишком притянуто за уши, но сейчас уже так не думаю :)

Спасибо за ответы!

← →
Ega23 © (2009-02-19 12:03) [5]

> Тогда значение по умолчанию
> не должно выбираться вообще, но в списке присутствовать
> должно,
> притом первым пунктом.

На самом деле это большой косяк стандартного TDBLookupCombo, что он не может на null-значение НД позиционироваться.

← →
KSergey © (2009-02-19 12:04) [6]

зачастую ключевое поле INT, однако автонумераторы в подавляющем большенстве случаев создают от нуля и далее (в положительную область). Таким образом ничто не мешает забронировать любые отрицательные значения для "особого смысла" (причем даже явно занести их в справочники)без боязни пересечения в любой инсталяции системы, и это будет много лучше NULL по причинам, указанным в [2].

← →
Johnmen © (2009-02-19 12:09) [7]

Такое поле д.б. NULL. Другие варианты говорят о том, что значение существует. А это не так.
Об этом говорит теория реляционных БД.
И надо разделять ХРАНЕНИЕ и ОТОБРАЖЕНИЕ, а не месить всё в одно корыто :)

← →
Kostafey © (2009-02-19 12:48) [8]

> [5] Ega23 © (19.02.09 12:03)

> На самом деле это большой косяк стандартного TDBLookupCombo,
> что он не может на null-значение НД позиционироваться.

Ну в моем случае это
<h:selectOneMenu ...
но не суть важно.

> [6] KSergey © (19.02.09 12:04)

> зачастую ключевое поле INT, однако автонумераторы в подавляющем
> большенстве случаев создают от нуля и далее (в положительную
> область). Таким образом ничто не мешает забронировать любые
> отрицательные значения для "особого смысла" (причем даже
> явно занести их в справочники)без боязни пересечения в любой
> инсталяции системы, и это будет много лучше NULL по причинам,
> указанным в [2].

А тут есть небольшой подводный камень.
MS SQL Server при добавлении новой записи в момент добаления присваивает ей
идентификатор -1.
У меня однажды возникла ситуация, когда такая запись участвовала в запросе
на выборку. Результат сначала сильно удивил...

Счет там начинается с 1, так что для служебный целей лучше использовать 0.

> [7] Johnmen © (19.02.09 12:09)

> Такое поле д.б. NULL. Другие варианты говорят о том, что
> значение существует. А это не так.
> Об этом говорит теория реляционных БД.
> И надо разделять ХРАНЕНИЕ и ОТОБРАЖЕНИЕ, а не месить всё
> в одно корыто :)

Угу, значит писать:

select ... union 0, "не указано"

но тогда чтобы в базе сохранить именно null потребуется некоторое
количество дополнительного кода, что тоже не очень удобно.

← →
Ega23 © (2009-02-19 12:50) [9]

> Такое поле д.б. NULL. Другие варианты говорят о том, что
> значение существует. А это не так.
> Об этом говорит теория реляционных БД.
> И надо разделять ХРАНЕНИЕ и ОТОБРАЖЕНИЕ, а не месить всё
> в одно корыто :)

В данной ситуации готов поспорить.
1. Жизнь штука многогранная. Если способ хранения данных, пусть и неправильный, помогает их отображению (работе с данными) - то пуркуа бы и не па? Разумную денормализацию ещё никто не отменял, да и не видел я реальных баз, которые соответствовали бы 4-й НФ. Всегда найдётся что-то "этакое".
2. NULL - штука сама по себе не сильно приятная. Хотя бы потому, что в одних случаях надо писать where T1.ID=12, а в других is not null. Не очень красиво получается.
3. Если я прописал в таблицу сразу после генерации некое "защищённое" значение, то не вижу причин, почему бы его не использовать.

← →
Ega23 © (2009-02-19 12:51) [10]

> MS SQL Server при добавлении новой записи в момент добаления
> присваивает ей идентификатор -1.

ЧЕГО????????

← →
Johnmen © (2009-02-19 12:53) [11]

> Угу, значит писать:
> select ...union 0, "не указано"

Не значит. Это ещё один пример, когда замешиваются в одно корыто ПОЛУЧЕНИЕ данных и их ОТОБРАЖЕНИЕ.

> но тогда чтобы в базе сохранить именно null потребуется
> некотороеколичество дополнительного кода, что тоже не очень
> удобно.

Например?

← →
Kostafey © (2009-02-19 12:59) [12]

> [10] Ega23 © (19.02.09 12:51)

Дочего же полезно на дельфимастер иногда заглядывать :)
Понял откуда эта -1. Н-нда, забавно. :)

← →
Johnmen © (2009-02-19 13:01) [13]

> Ega23 © (19.02.09 12:50) [9]

Я говорю про теорию и идеологию.
Каждый волен от этого отступать как угодно далеко, если его жизнь станет легче. Но при этом он должен осознавать и просчитывать, что будущее может (именно МОЖЕТ, т.е. не обязательно) его напрячь сильнее, чем он сэкономил.

← →
Kostafey © (2009-02-19 13:04) [14]

> [11] Johnmen © (19.02.09 12:53)
>
> > Угу, значит писать:
> > select ...union 0, "не указано"
>
> Не значит. Это ещё один пример, когда замешиваются в одно
> корыто ПОЛУЧЕНИЕ данных и их ОТОБРАЖЕНИЕ.

Тогда как?

> > но тогда чтобы в базе сохранить именно null потребуется
>
> > некотороеколичество дополнительного кода, что тоже не
> очень
> > удобно.
>
> Например?

Ну схематично, если в сиписке
select ...union 0, "не указано"
тогда
<h:selectOneMenu...
вернет 0

Значит должен быть Integer = null (ето java), который мы и
сохраняем в таблицу.

← →
Ega23 © (2009-02-19 13:05) [15]

> Но при этом он должен осознавать и просчитывать, что будущее
> может (именно МОЖЕТ, т.е. не обязательно) его напрячь сильнее,
> чем он сэкономил.

Золотые твои слова. Вот эту цитату следует на заглавную страницу конференции "Базы" вывести. Наряду с "В DBGrid нет никаких данных!"

← →
Ega23 © (2009-02-19 13:06) [16]

> Дочего же полезно на дельфимастер иногда заглядывать :)
> Понял откуда эта -1. Н-нда, забавно. :)

Что там у тебя за -1 появилась?

← →
Медвежонок Пятачок © (2009-02-19 13:06) [17]

лучше оставлять пустое поле.
напрмер иногда нужно посчитать или выбрать всех, у кого, оно на заполнено.

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

а если это только для отображения, то выкручиваться средствами сервера типа оркалового decode(field,null,"empty",field)

← →
Johnmen © (2009-02-19 13:08) [18]

> Kostafey © (19.02.09 13:04) [14]

Я не знаю яву.

← →
clickmaker © (2009-02-19 13:09) [19]

вообще, если есть куча справочников, то нет смысла в каждом писать "не указано". Дублирование информации.
Такие строки-константы лучше отдельно хранить. В БД или в ресурсах - другой вопрос.

← →
Kostafey © (2009-02-19 13:10) [20]

> [16] Ega23 © (19.02.09 13:06)
>
> > Дочего же полезно на дельфимастер иногда заглядывать :
> )
> > Понял откуда эта -1. Н-нда, забавно. :)
>
>
> Что там у тебя за -1 появилась?

Да это просто идентификатор текущей записи. В момент добавления
он не определен, а я просто ее инициализировал -1, это было уже
давно, вот и забыл.

P.S. смеялся долго :)

← →
Игорь Шевченко © (2009-02-19 13:11) [21]

Johnmen © (19.02.09 12:09) [7]

> Такое поле д.б. NULL. Другие варианты говорят о том, что
> значение существует. А это не так.
> Об этом говорит теория реляционных БД.
> И надо разделять ХРАНЕНИЕ и ОТОБРАЖЕНИЕ, а не месить всё
> в одно корыто :)

"Почему-то, иногда любят использовать поля, в которых не стоит ограничение NOT NULL. Вроде бы ничего страшного. Если встречается значение NULL, значит, его нужно интерпретировать как некоторое значение по умолчанию. Но в этом и проблема. В любом месте, где встречается это поле, нужно делать проверки или использовать функции вида isnull. Если случайно забыть, можно получить ошибку приведения типа в целевом языке или неожиданный результат в арифметических операциях в SQL. Второй вариант, как правило, не вызывает больших неприятностей. Зато первый имеет особенность вызывать через некоторое время ошибки в программе, например, если появляется новый способ добавить запись в базу, не определяя все поля.

Безусловное удобство заключается как раз в отсутствии необходимости инициализировать все поля таблицы. Но такой же эффект можно получить просто определив для столбца значение по умолчанию.

Конечно, есть ситуации, когда использование NULL-значений очень удобно. В классике, они означают отсутствие значения: или оно будет определено позже, либо вообще никогда. Стоит отметить, что только таким образом можно определить пустое значение для столбца с ограничением внешним ключом.

NULL-значения требуют постоянных проверок. От этих проверок можно легко уйти, запретив использовать NULL-значения в столбцах. И если для столбца значение NULL не является специальным, лучше их запретить."

http://www.gurenkov.net/articles/database_patterns_1/

Тоже мнение.

← →
clickmaker © (2009-02-19 13:14) [22]

> И если для столбца значение NULL не является специальным,
> лучше их запретить

насчет булевых полей, кстати, да. Как-то непривычно видеть там null... типа "может быть" -)

← →
Johnmen © (2009-02-19 13:15) [23]

> Игорь Шевченко © (19.02.09 13:11) [21]

Хорошее мнение.
А у нас тут лишь подмножество этого мнения - NULL в ссылочном поле. Про него и говорим.
Т.е. "для столбца значение NULL является специальным".

← →
Kostafey © (2009-02-19 13:15) [24]

> [18] Johnmen © (19.02.09 13:08)

Да в этом и не суть, просто запись хранится в объекте,
идентификатор привязываемого справочника - одно из свойств
объекта. Тип числовой. А числовой тип может быть 0, но не null,
значит нужно еще отдельно объектный тип, чтобы присвоить ему
злочастный null и уже его сохраняет, словом неудобно.

← →
Johnmen © (2009-02-19 13:18) [25]

> Kostafey © (19.02.09 13:15) [24]

Тогда [9] и [13].

← →
Ega23 © (2009-02-19 13:18) [26]

> вообще, если есть куча справочников, то нет смысла в каждом
> писать "не указано". Дублирование информации.
> Такие строки-константы лучше отдельно хранить. В БД или
> в ресурсах - другой вопрос.

Ну тут уже от сущности зависит. Хотя я с тобой во многом согласен. Года 2 назад ты крайне любопытную стратегию предложил по организации такой единой "помойки". Взял на вооружение... :)

> Медвежонок Пятачок © (19.02.09 13:06) [17]
> если нулл, то все просто, если не нулл, то в запросе потребуется
> дополнительно сравнивать с константой.

Блин, а сравнение с NULL - это не сравнение с константой? :)

Я, собственно, почему за такой подход: в FK всегда будет строгое значение.

← →
Игорь Шевченко © (2009-02-19 13:20) [27]

> Блин, а сравнение с NULL - это не сравнение с константой?
> :)

Ни в коем разе

← →
Johnmen © (2009-02-19 13:23) [28]

> Я, собственно, почему за такой подход: в FK всегда будет
> строгое значение.

Строгое значение ничем не лучше строгого отсутствия значения :)

← →
Ega23 © (2009-02-19 13:23) [29]

> Ни в коем разе

Да ладно.
Не вижу разницы между
select * from table where column is not null
и
select * from table where column>1

← →
Johnmen © (2009-02-19 13:28) [30]

> Ega23 © (19.02.09 13:23) [29]
> Не вижу разницы между

А она есть.

← →
Ega23 © (2009-02-19 13:28) [31]

> А она есть.

Аргументируй.

← →
Johnmen © (2009-02-19 13:45) [32]

> Ega23 © (19.02.09 13:28) [31]
> Аргументируй.

Чего аргументировать?
Что
> select * from table where column is not null
возвращает только непустые, а
> select * from table where column>1
большие 1 непустые
?

← →
Ega23 © (2009-02-19 13:48) [33]

> большие 1 непустые

Они все непустые, если NOT NULL.

← →
Johnmen © (2009-02-19 13:50) [34]

> Ega23 © (19.02.09 13:48) [33]
> Они все непустые, если NOT NULL.

Непустые, и что?

← →
Медвежонок Пятачок © (2009-02-19 14:04) [35]

Блин, а сравнение с NULL - это не сравнение с константой? :)

null это "корзырная константа". а для некозырной надо всегда знать, что там написано вместо нула.

← →
Petr V. Abramov © (2009-02-19 14:28) [36]

> Ega23 © (19.02.09 13:23) [29]

если индексов нет - почти :) одно итоже
если есть индекс

column > 1 это index range scan
column is not null - или index full scan, или table access full, в зависимости от кол-ва null`ов в столбце

по теме - мне больше нравится ссылка на "не задано", избавляет от outer join`ов
хотя в жирной таблице, где "незаполнных" значений много и имеет смысл индекс, лучше оставить null

← →
Ega23 © (2009-02-19 14:38) [37]

> если индексов нет - почти :) одно итоже
> если есть индекс
>
> column > 1 это index range scan
> column is not null - или index full scan, или table access
> full, в зависимости от кол-ва null`ов в столбце

О! А это уже пошли тонкости реализаций конкретных СУБД.
Что, безусловно, тоже надо учитывать при выборе стратегии.

← →
Sergey Masloff (2009-02-19 14:43) [38]

Ega23 © (19.02.09 14:38) [37]
а что есть базы в которых null в индексах хранится? сомневаюсь

Petr V. Abramov © (19.02.09 14:28) [36]
Если таблица нежирная то фуллскан даже лучше. Если жирная - рост индекса крайне нежелателен. То есть NULL почти всегда лучше. Так же?

← →
Ega23 © (2009-02-19 14:50) [39]

> а что есть базы в которых null в индексах хранится? сомневаюсь

ЕМНИП, в MSSQL если строго один раз NULL встречается - то индексируется.

← →
Sergey Masloff (2009-02-19 14:59) [40]

Ega23 © (19.02.09 14:50) [39]
Кажется изменяет. Но не уверен - мое общение с MSSQL окончилось на версии 7

← →
KSergey © (2009-02-19 15:04) [41]

> Johnmen © (19.02.09 13:01) [13]
> Я говорю про теорию и идеологию.

Да кому она нужна "абстрактная теория"? Её и так все знают.
Речь о практическом применении, а не о "как красиво сделать на бумаге".

← →
Petr V. Abramov © (2009-02-19 15:04) [42]

> Sergey Masloff (19.02.09 14:43) [38]

> Так же?

не так ;)

> Если таблица нежирная то фуллскан даже лучше.

если таблица - десяток блоков и больше, а нужно 1-2 значения более-менее :) уникальных, лучше индекс

> Если жирная - рост индекса крайне нежелателен

вот это не понял. а куда деваться-то? не индексировать?
если имелось в виду, что за счет null`ов размер индекса можно сократить - тогда ессно согласен

← →
Sergey Masloff (2009-02-19 15:10) [43]

Petr V. Abramov © (19.02.09 15:04) [42]
в частности если лезть. У нас сейчас 128 гиг оперативки. Для таблиц 100000 записей - fullscan летает (меряли)

Про второе - естественно про то что null не пишется в индекс.

← →
KSergey © (2009-02-19 15:34) [44]

> Sergey Masloff (19.02.09 15:10) [43]
> Про второе - естественно про то что null не пишется в индекс.

Это какая-то конкретная известная реализация или типичное дело?

← →
Sergey Masloff (2009-02-19 15:40) [45]

KSergey © (19.02.09 15:34) [44]
Типичное

← →
Petr V. Abramov © (2009-02-19 15:55) [46]

> Sergey Masloff (19.02.09 15:10) [43]

> Для таблиц 100000 записей - fullscan летает (меряли)

то, что на твоей течнике летает - это понятно. Но я уверен, что при выборке десятка значений по индексу будет летать еще быстрее

← →
atruhin © (2009-02-19 17:00) [47]

> [36] Petr V. Abramov © (19.02.09 14:28)
> column > 1 это index range scan
> column is not null - или index full scan, или table access
> full, в зависимости от кол-ва null`ов в столбце

> [45] Sergey Masloff (19.02.09 15:40)
> Типичное

Ну здесь необходимо указать о какой БД речь. Например FB хранит NULL в индексе.
Только что проверил:
select ...
where CL_MASTER_REF is null
выборка по индексу : PLAN (S_CLASSES INDEX (FK_S_CLASSES_2))

select ...
where CL_MASTER_REF is not null
выборка full scan : PLAN (S_CLASSES NATURAL), но идеентичный запрос

select ...
where CL_MASTER_REF >= 0
использует индекс: PLAN (S_CLASSES INDEX (FK_S_CLASSES_2))

Т.е. с точки зрения производительности, есть или нет NULL значения не имеет, по крайней мере в FB

← →
MsGuns © (2009-02-19 17:14) [48]

Интересно как апологеты значения "не указано" (типа -1, как тут говорили) собираются решать проблему записи этой -1 в поле, ссылающееся на справочник ?

← →
Kinda (2009-02-19 17:17) [49]

Непонятно о какой-такой "проблеме" идет речь...

← →
Ega23 © (2009-02-19 17:31) [50]

> Интересно как апологеты значения "не указано" (типа -1,
> как тут говорили) собираются решать проблему записи этой
> -1 в поле, ссылающееся на справочник ?

Гм... А что непонятного?

create table childtable ( chid int identity(1,1) not null, mid int null, chldname varchar(32) not null, constraint pk_childtable primary key (chid) ) go create table mastertable ( mid int not null, mname varchar(32) not null, constraint pk_mastertable primary key (mid) ) go alter table childtable add constraint fk_childtab_reference_masterta foreign key (mid) references mastertable (mid) go insert into mastertable (mid, name) values (-1, "Не определено") insert into mastertable (mid, name) values (1, "Значение 1") insert into mastertable (mid, name) values (2, "Значение 2") go insert into childtable (mid,chldname) values (-1, "Not defined Child 1") insert into childtable (mid,chldname) values (-1, "Not defined Child 2") insert into childtable (mid,chldname) values (-1, "Not defined Child 3") insert into childtable (mid,chldname) values (1, "Defined Child 1") insert into childtable (mid,chldname) values (2, "Defined Child 2") go

← →
Kostafey © (2009-02-19 17:32) [51]

> [48] MsGuns © (19.02.09 17:14)

Очевидно, добавив эту самую запись в справочник ;)

Можно и иначе, записывать в таблицу значение null,
а "не указано" дописывать в комбобоксы (или что-то другое)
вручную.

> [49] Kinda (19.02.09 17:17)

Чего именно не понятно?
Ясно, что можно и так и так сделать
вопрос как лучше, технологичнее, удобнее, etc...

← →
Kostafey © (2009-02-19 17:32) [52]

> [50] Ega23 © (19.02.09 17:31)

опредили-сс :)

← →
MsGuns © (2009-02-19 17:34) [53]

>Kostafey © (19.02.09 17:32) [51]
>Очевидно, добавив эту самую запись в справочник ;)

Замечательное решение ! И, главное, дальновидное :)

← →
Kinda (2009-02-19 17:35) [54]

> > [49] Kinda (19.02.09 17:17)
>
> Чего именно не понятно?
> Ясно, что можно и так и так сделать
> вопрос как лучше, технологичнее, удобнее, etc...

По сабжу я ответил в [3], та что там мне все понятно.

А непонятно в чем заключается проблема, высказанная в [48]

← →
Kinda (2009-02-19 17:44) [55]

А насчет "технологичнее" отвечу так: огромных базах с большим кол-вом таблиц нуллы все-равно приходится обрабатывать в запросах..., приходится писать когромное количество проверок на нуллл...

Оттого и желание как можно уменьшить их количество....

← →
Kostafey © (2009-02-19 18:57) [56]

> [54] Kinda (19.02.09 17:35)

Да, конечно, приношу свои извинения.
Просто сарказм MsGuns сбил с толку :)

> [53] MsGuns © (19.02.09 17:34)
> >Kostafey © (19.02.09 17:32) [51]
> >Очевидно, добавив эту самую запись в справочник ;)
>
> Замечательное решение ! И, главное, дальновидное :)

Ах ну надо же! Вам тоже так кажется? :)
Или есть еще и свое мнение?

← →
Sergey Masloff (2009-02-19 21:05) [57]

Kinda (19.02.09 17:44) [55]
Ну у меня база растет 17 Гб в неделю. Общий размер сейчас даже не знаю но в терабайтах точно. Никакого огромного количества проверок на NULL как-то не приходится писать. Никак не больше чем было бы проверок на -1 или подобных суррогатов ;-)

← →
KSergey © (2009-02-19 21:27) [58]

> Sergey Masloff (19.02.09 21:05) [57]
> Ну у меня

Зависит не от размера, а сложности, очевидно. Выраженной хотя бы в количестве таблиц и их взаимосвязях: одно дело 3 таблицы, которые растут, пусть и интенсивно + к ним десяток справочникв, и совсем другое дело пол сотни "опонрых" справочников, описывающих многообразие вариантов, причем справочники между собой связанные + к ним рабочие таблицы, подвязанные ко многим справочникам еще и сообношением много ко многим через связывающие таблицы. Ну да вы это и сами понимаете.

> MsGuns © (19.02.09 17:34) [53]
> >Очевидно, добавив эту самую запись в справочник ;)
> Замечательное решение ! И, главное, дальновидное :)

Можно для тупых расшифровать?

← →
Sergey Masloff (2009-02-19 22:01) [59]

KSergey © (19.02.09 21:27) [58]
не три таблицы
;-)
Хотя любую по сложности систему можно на 2 таблицах организовать.

← →
Johnmen © (2009-02-19 23:51) [60]

> Kinda (19.02.09 17:44) [55]
> А насчет "технологичнее" отвечу так: огромных базах с большим
> кол-вом таблиц нуллы все-равно приходится обрабатывать в
> запросах..., приходится писать когромное количество проверок
> на нуллл...

Мне жаль Вас. И Ваших юзеров...

← →
MsGuns © (2009-02-19 23:56) [61]

>KSergey © (19.02.09 21:27) [58]
>> Замечательное решение ! И, главное, дальновидное :)
>Можно для тупых расшифровать?

Что тебя затруднило: замечательность или дальновидность ?

← →
pasha_golub © (2009-02-20 00:22) [62]

> Petr V. Abramov © (19.02.09 14:28) [36]
>
>

>
> column > 1 это index range scan
> column is not null - или index full scan, или table access
> full, в зависимости от кол-ва null`ов в столбце

Вранье. Нуллы тоже в индексах сортирууются. И у продвинутых СУБД есть параметры куда их включать в конец али в головую

← →
Игорь Шевченко © (2009-02-20 00:26) [63]

> И у продвинутых СУБД есть параметры куда их включать в конец
> али в головую

Только не в индекс, а в результат, нес па ?

← →
pasha_golub © (2009-02-20 00:26) [64]

> KSergey © (19.02.09 15:34) [44]
>
> > Sergey Masloff (19.02.09 15:10) [43]
> > Про второе - естественно про то что null не пишется в
> индекс.
>
> Это какая-то конкретная известная реализация или типичное
> дело?
> <Цитата>
>
> Sergey Masloff (19.02.09 15:40) [45]
>
> KSergey © (19.02.09 15:34) [44]
> Типичное
> <Цитата>

Не факт. Хотя не имею на руках доказательств, но
СREATЕ ... NULLS { FIRST | LAST }
в некоторой СУБД наталкивают на мысли, что таки хранятся.

← →
pasha_golub © (2009-02-20 00:28) [65]

> Игорь Шевченко © (20.02.09 00:26) [63]

Может быть и па. Но зачем тогда индексу в Потсгресе указывать при создании откуда у него будут рости NULLы?

> Sergey Masloff (19.02.09 21:05) [57]

> Никак не больше чем было бы проверок на -1 или подобных
> суррогатов ;-)

это понятно, но вот кол-во outer join`ов растет. Которые не абсолютное, но зло

pasha_golub © (20.02.09 00:28) [65]

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

> Kostafey © (19.02.09 11:49) [4]

+1

я делаю всегда так:

CREATE TABLE [dbo].[tEmployees]( [EmployeeID] [int] IDENTITY(100,1) NOT NULL, [Surname] [nvarchar](50) COLLATE Cyrillic_General_CI_AS NULL, [Name] [nvarchar](50) COLLATE Cyrillic_General_CI_AS NULL, [Patronymic] [nvarchar](50) COLLATE Cyrillic_General_CI_AS NULL, [JobTitleID] [int] NULL CONSTRAINT [DF_tEmployees_JobTitleID] DEFAULT ((0)), CONSTRAINT [PK_tEmployees] PRIMARY KEY CLUSTERED ( [EmployeeID] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY]

CREATE TABLE [dbo].[tJobTitles]( [JobTitleID] [int] IDENTITY(0,1) NOT NULL, [JobTitle] [nvarchar](50) COLLATE Cyrillic_General_CI_AS NULL, [SmJobTitle] [nvarchar](25) COLLATE Cyrillic_General_CI_AS NULL, CONSTRAINT [PK_tJobTitles] PRIMARY KEY CLUSTERED ( [JobTitleID] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY]

Где: JobTitleID (0) это <Должность>, а далее в списке уже то, что необходимо. Проблем пока не возникало.

> Василий Жогарев © (20.02.09 09:35) [70]

Забавно видеть таблицу должностей
0 Ой, что это!? ??? 1 Дворник Дв 2 Слесарь Сл 3 NULL NULL 4 NULL NULL 5 NULL NULL 6 NULL NULL 7 Студент Ст
:)

← →
Kinda (2009-02-20 10:21) [72]

> Мне жаль Вас. И Ваших юзеров...

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

> pasha_golub (20.02.2009 0:26:04) [64]

Меня не наталкивает, по данному куску понять нельзя, что оно задает, порядок выдачи или хранения. Наблюдениями это тоже не подтвердить, тут надо смотреть документацию.

> Kinda (20.02.2009 10:21:12) [72]

Я против хранения спец значений, поскольку снижается производительность, из-за лишних проблем, кроме того проблемы с локализацией, абстрагирование и много всяких НО, в тоже время это легко реализуется при выводе на клиенте, ему даже можно позволить самому задавать свой текст, при том у каждого свой. Говорю на личном опыте, есть постороння БД, и в полях, где NULL, где какое то значение по умолчанию, а где то полный бардак для подобных полей, кто как хотел так и давал значения, и можно встретить такой вывод

значение
Пусто
Нет
Х
NULL
значение
...

Это самый худший вариант, особенно для текстовых полей, на все варианты не напишешься разных проверок в запросе.

← →
Kinda (2009-02-20 13:44) [75]

> Anatoly Podgoretsky © (20.02.09 13:29) [74]

Так собственно о том и речь была, чтобы запретить нулл, а разрешить только
значения из справочника (внешний ключ), а для случаев, когда поле по каким-то причинам нельзя заполнить, предусмотреть в справочнике спец. запись.

Согласен с тем что данный подход не идеален во всех случаях, а в некоторых вообще недопустим. Такой подход я применяю для полей которые часто используются в группировках и джойнах.

> Anatoly Podgoretsky © (20.02.09 13:29) [73]

> Меня не наталкивает, по данному куску понять нельзя, что
> оно задает, порядок выдачи или хранения. Наблюдениями это
> тоже не подтвердить, тут надо смотреть документацию.

Документацию смотрел. Однозначного ответа не нашел. Однако, если порядок выдачи, то логичнее было бы сотворить нечто

SELECT ... ORDER colname DESC [NULLS FIRST|LAST]

Фраза из доки:
The NULLS options are useful if you need to support “nulls sort low” behavior, rather than the default “nulls sort high”, in queries that depend on indexes to avoid sorting steps.

Про хранение не сказано ни слова.

> Про хранение не сказано ни слова.

По-моему - можно. Сейчас уже не помню, всю доку читал где-то весной, но что-то такое "проскакивало"...

> Документацию смотрел. Однозначного ответа не нашел. Однако,
> если порядок выдачи, то логичнее было бы сотворить нечто
>
> SELECT ... ORDER colname DESC [NULLS FIRST|LAST]

Как SELECT связан с созданием индексов ?

>
> Как SELECT связан с созданием индексов ?

Если НУЛЛы не хранились бы в индексе, то логичней было бы ввесте такую конструкцию, которая явно указывает на сортировку по выборке. Если же все-таки в CREATE INDEX указыается этот факт, то я предполагаю, что нуллы таки храняться.

> Ega23 © (20.02.09 15:44) [78]
>
>
>
> По-моему - можно

Там очень неоднозначно все, ибо contrib модули очень богаты как оказалось. И помимо официально поддерживаемых индексов, есть еще и специфические, которыми люди тоже пользуются. Плюс никто не мешает написать свою реализацию индекса, а там хоть бобриком скакай.

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

А её разве не существует?
И всё же, как SELECT связан с созданием индексов ?

> Если же все-таки в CREATE INDEX указыается этот факт, то
> я предполагаю, что нуллы таки храняться.

А не затруднит выдержку из доки на предмет указания хранения NULL-ов при создании индекса ? Это не наезд, просто интересно (с)

> pasha_golub (20.02.2009 15:33:16) [76]

Не логично, это должен делать программист в каждом запросе, а во втором глобально система без участия программиста, кроме создания индекса.
И скажи где кроме выдачи это может понадобиться?

> Ega23 (20.02.2009 15:44:18) [78]

Вообще то смешно говорить об хранение множества, в котором вообще отсутствует такое понятие как порядок хранения.
И даже выдачи если не использован предикат ORDER BY

> Игорь Шевченко (20.02.2009 15:47:19) [79]

Хм, интересный вопрос.

> pasha_golub (20.02.2009 16:02:20) [80]

Оракл штука весьма странная, доступная только жрецам.

> MsGuns © (19.02.09 23:56) [61]
> >KSergey © (19.02.09 21:27) [58]
> >> Замечательное решение ! И, главное, дальновидное :)
> >Можно для тупых расшифровать?
>
> Что тебя затруднило: замечательность или дальновидность ?

Хотелось бы понять к чему его (не)замечательность может привести в "дальновидной" перспективе. На практике.

Anatoly Podgoretsky © (20.02.09 16:32) [86]

> Оракл штука весьма странная, доступная только жрецам.

Это миф, ведущий свою историю с ранних версий

← →
kaif (2009-02-20 22:55) [89]

Я стараюсь по возможности всегда накладывать ограничение NOT NULL.

Часто в справочниках использую значение ID=0 для "пустых значений":

ID NAME
0 ""

Это может вызвать возражения.
Но на практике эта идеология обычно себя оправдывает.

> kaif (20.02.2009 22:55:29) [89]

Если делать средствами сервера и принять несколько условностей, то это вполне работает.
Хуже как я уже писал, когда и NULL и "пустые" значения. А ведь есть случае когда ни одно значения нельзя принять за пустое.

> Anatoly Podgoretsky © (21.02.09 00:52) [90]
> А ведь есть случае когда ни одно значения нельзя принять за пустое.

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

тут пр любом подходе как и во всяком деле главное лоб не расшибить от усердия

> KSergey (21.02.2009 8:32:31) [91]

В соответствии с типом + NULL

Стратегия пустых полей Найти похожие ветки