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

← →
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ы?

← →
Petr V. Abramov © (2009-02-20 00:42) [66]

> pasha_golub © (20.02.09 00:22) [62]

> Вранье.

на поляну?

← →
Petr V. Abramov © (2009-02-20 00:45) [67]

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

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

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

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

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 модули очень богаты как оказалось. И помимо официально поддерживаемых индексов, есть еще и специфические, которыми люди тоже пользуются. Плюс никто не мешает написать свою реализацию индекса, а там хоть бобриком скакай.

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