powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите насчет NULLов в базе
53 сообщений из 53, показаны все 3 страниц
Подскажите насчет NULLов в базе
    #33190362
Kite
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений. Верно ли это утверждение и если верно, то где найти обоснование, что почитать?
И может поделитесь рассуждениями и наблюдениями из опыта, насколько мешают NULL значения при эксплуатации БД.
Спасибо заранее...
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33190368
Фотография XM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kite wrote:
> Где-то встречала выражение, что хорошо спроектированная БД не должна
> содержать большого количества NULL значений. Верно ли это утверждение и
> если верно, то где найти обоснование, что почитать?
http://www.dbdebunk.com/page/page/1706744.htm
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33190858
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KiteГде-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений.
На мой взгляд, все определяется здравым смыслом. А здравый смысл подсказывает что в реальной системе очень большое количество полей может быть необязательно к заполнению. Простейший пример - справочник партнеров который содержит кроме наменования инн, оконх, окпо, егрн значения которых в большинстве случаев неизвестно.

По крайней мере про старые версии Sybase и MS SQL говорили что сервер более оптимально располагает на страницах NOT NULL данные, что приводит к небольшому ускорению дисковых операций. Но по моему не стоит специально обращать внимание на это.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33190902
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Простейший пример - справочник партнеров который содержит кроме наменования инн, оконх, окпо, егрн значения которых в большинстве случаев неизвестно.Это, увы не пример удачной системы. А если появятся ещё 5 реквизитов (например, введут к-л новые требования) ? Будете поля добавлять ?

Впрочем, некоторое кол-во нулов это вполне нормальная ситуация. Главное, чтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33190994
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot LSVЭто, увы не пример удачной системы. А если появятся ещё 5 реквизитов (например, введут к-л новые требования) ? Будете поля добавлять?
[/quot]
Угу, иначе кто мне деньги платить будет за поддержку ;)
А по поводу хранения реквизитов в отдельной таблице или в основной, достаточно много рассуждений на этом форуме. Скажу сразу у нас в системе реализованы оба подхода. Все что входит в "анкету" лица сидит в основной таблице, все доп. данные в динамических классификаторах к анкете. Как обычно всегда требуется баланс между удобством и производительностью.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33191096
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дейт с Давином с самого начала были против null'ов. И основной упор делали во-первых на то что в современных СУБД под null понимается 2 разных понятия - собственно null и unk (unknown)... во-вторых на сложности с формулированием предиката для отношения содержащего null

С первым я полностью согласен, со вторым где-то на 30% ;)

Правда в реальных системах null или какая-либо константа его заменяющая - это меньшее из зол
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33191153
aechka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LSV[quot ]Простейший пример - справочник партнеров который содержит кроме наменования инн, оконх, окпо, егрн значения которых в большинстве случаев неизвестно.Это, увы не пример удачной системы. А если появятся ещё 5 реквизитов (например, введут к-л новые требования) ? Будете поля добавлять ?

А как по-другому?
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33191367
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KiteГде-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений. Верно ли это утверждение и если верно, то где найти обоснование, что почитать?
И может поделитесь рассуждениями и наблюдениями из опыта, насколько мешают NULL значения при эксплуатации БД.
Спасибо заранее...Я бы сказал немного по-другому: верно, что хорошо нормализованная БД не должна содержать большого количества NULL значений. Но хорошо спроектированная и хорошо нормализованная БД - далеко не всегда тождественные понятия.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33191567
Kite
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо всем за высказанные мнения.
А как ведут себя индексы, построенные по полям, содержащим множество значений NULL?
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33191876
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полностью избавленная от null-ов БД - полностью декомпозированная - для
каждого атрибута своя таблица )))))


Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33194157
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kite

К сожалению, поведение индексов разнится в зависимости от СУБД
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33194907
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Kite. Не обращайте внимания. сколько Вам нужно NULL, столько и делайте.
В кадровсой программе возможны NULL
Дата смерти
Дата Увольнения
Дата выхода на пенсию
Имеющиеся правительственные награды
Телефон
И дофига других.

Типа размера обуви, которая нужна только тем, кто имеет право на на выдачу обуви как спецодежды.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33197621
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KiteА как ведут себя индексы, построенные по полям, содержащим множество значений NULL?
Значение NULL в подавляющем большинстве случаев низкоселективно, а следовательно использование b-индекса для выбора записей по условию field is null будет неэффективным.

В принципе я вижу три варианта:

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

исключать null записи из индекса

хранить null в некотором особом списке

Третий из них - не знаю, работает ли где-то, и несколько странен. Он был бы удобен, но непонятно как обобщить это решение для индекса по нескольким полям.

Вторым подходом пользуется Oracle; вроде упоминали, что такая настройка есть в Access, может и еще где-то. Таким образом уменьшаются потери на хранение ненужных данных в индексе, но индекс становится менее применим (не может быть использован в некоторых запросах, например select count).

Первый - вроде наиболее прост в понимании :)
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33197711
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Значение NULL в подавляющем большинстве случаев низкоселективно,

как раз правота этого утверждения сильно зависит от того как эту БД проектировали... можно сделать и высокоселективным ;)
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33197790
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
исключать null записи из индекса
Так работают многие промышленные СУБД. Точно знаю про MSSQL и Oracle.
Поэтому выражение:
WHERE MyField is null
низкопроизводительно.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33199741
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuriЗначение NULL в подавляющем большинстве случаев низкоселективно,

как раз правота этого утверждения сильно зависит от того как эту БД проектировали... можно сделать и высокоселективным ;)
Читаем: "... в подавляющем большинстве".

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL> select
   2     round (max (ratio),  2 ) "max",
   3     round (min (ratio),  2 ) "min",
   4     round (avg (ratio),  2 ) "avg",
   5     round (stddev (ratio),  2 ) "stddev"
   6   from
   7     (select t.owner, t.table_name, t.num_rows, i.num_rows,
   8      i.num_rows / t.num_rows *  100  ratio
   9      from dba_indexes i, dba_tables t
  10      where i.index_type <> 'CLUSTER'
  11      and t.owner = i.owner and t.table_name = i.table_name
  12      and t.num_rows > greatest (i.num_rows,  1000 ));

       max        min        avg     stddev
---------- ---------- ---------- ----------
        100            0        33 , 52        42 , 59 
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33199815
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVПоэтому выражение: WHERE MyField is null
Не только и не столько поэтому. В следующем примере consistent gets - это логические чтения.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
SQL> create table sn as
   2   select rownum i, case when mod (rownum,  5 ) =  0  then null else rownum end j
   3   from dba_objects, dba_objects
   4   where rownum <=  1000000 ;

Table created.

SQL> create index sn_i on sn (coalesce (j, - 1 ));

Index created.

SQL> create bitmap index sn_bi on sn (j);

Index created.

SQL> select /*+ FULL(sn) */ * from sn where j is null;

 200000  rows selected.

Elapsed:  00 : 00 : 07 . 79 

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=ALL_ROWS (Cost= 584  Card= 207040  Bytes= 5383040 )
    1      0    TABLE ACCESS (FULL) OF 'SN' (TABLE) (Cost= 584  Card= 207040  Bytes= 5383040 )

Statistics
----------------------------------------------------------                      
       15356   consistent gets                                                    

SQL> select /*+ INDEX(sn sn_bi) */ * from sn where j is null;

 200000  rows selected.

Elapsed:  00 : 00 : 07 . 73 

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=ALL_ROWS (Cost= 1426  Card= 207040  Bytes= 5383040 )
    1      0    TABLE ACCESS (BY INDEX ROWID) OF 'SN' (TABLE) (Cost= 1426  Card= 207040  Bytes= 5383040 )
    2      1      BITMAP CONVERSION (TO ROWIDS)
    3      2        BITMAP INDEX (SINGLE VALUE) OF 'SN_BI' (INDEX (BITMAP))

Statistics
----------------------------------------------------------                      
       15285   consistent gets                                                    

SQL> select /*+ INDEX(sn sn_i) */ * from sn where coalesce (j, - 1 ) = - 1 ;

 200000  rows selected.

Elapsed:  00 : 00 : 08 . 15 

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=ALL_ROWS (Cost= 4  Card= 207040  Bytes= 5383040 )
    1      0    TABLE ACCESS (BY INDEX ROWID) OF 'SN' (TABLE) (Cost= 4  Card= 207040  Bytes= 5383040 )
    2      1      INDEX (RANGE SCAN) OF 'SN_I' (INDEX) (Cost= 3  Card= 4143 )

Statistics
----------------------------------------------------------                      
       28967   consistent gets                                                    
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33200330
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня вот так
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
 select
      round (max (ratio),  2 ) "max",
      round (min (ratio),  2 ) "min",
      round (avg (ratio),  2 ) "avg",
      round (stddev (ratio),  2 ) "stddev"
    from
      (select t.owner, t.table_name, t.num_rows, i.num_rows,
       i.num_rows / t.num_rows  ratio
       from dba_indexes i, dba_tables t
      where i.index_type <> 'CLUSTER'
      and t.owner = i.owner and t.table_name = i.table_name
      and t.num_rows> 0  and (t.num_rows> 100  or i.num_rows> 100 )) --> greatest (i.num_rows, 1000));
maxminavgstddev61.0100.972.21

Но за примером высокой селективности далеко ходить также не надо. Например, взять так часто используемое отношение наследования и одно из возможных его представлений в РМД в виде одной таблицы на всю иерархию. Таблица должна содержать объединение всех атрибутов всех сущностей связанных наследованием... Далее достаточно чтобы какой-либо класс желательно выше по иерархии имел наибольшее количество объектов-записей...
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33201686
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuriУ меня вот так
Хм. А приведенные Вами цифры - все в процентах? (спрашиваю, поскольку у Вас из селекта выпало умножение на сто, а сами цифры... пожалуй что неожиданные в другую сторону, прежде всего дико низкое среднее значение).

funikovyuriНо за примером высокой селективности далеко ходить также не надо.
Вопрос в частоте таких примеров. Как видите, у меня поиск тоже нашел табличку, где есть null-ы, но их количество ничтожно. Вопрос - как часто такое вcтречается и как часто в таких таблицах нужно искать по is null. Когда такое происходит - меня не особо напрягает создать соответствующий "более хитрый" индекс. А un mass все же null прискорбно неселективен :)
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33202357
Slider_spb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть понятие внешнего ключа (FK). Если NULL не будет, какое значение должно содержать поле внешнего ключа в записи, не имеющее связи с подчиненной сущностью?
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33202407
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Slider_spb
Боюсь, я не понял связи Вашего вопроса с темой и предыдущим обсуждением. Не расшифруете, что Вы имели в виду?
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33202548
27 понуро бредущих кроликов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Slider_spbЕсть понятие внешнего ключа (FK). Если NULL не будет, какое значение должно содержать поле внешнего ключа в записи, не имеющее связи с подчиненной сущностью?

FK подразумевает связь с первичным ключем, скажем, справочной таблицы.
А NULL в PK - эт , мягко говоря, странно...
Если вы имеете ввиду NULL в поле FK - то смысл FK , который ссылается на несуществующие записи?

целочная ссылочность, однако...
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33202568
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
27 понуро бредущих кроликов Если вы имеете ввиду NULL в поле FK - то смысл FK , который ссылается на несуществующие записи?

целочная ссылочность, однако...
одно другому не противоречит. ссылочная целостность в смысле отсутствия в фк значений, не заданных в ПК (кроме случаев неопределенных родительских записей) - т.е. это частный случай ссылочной целостности. Частный случай - дерево с корнями, чьи родители неопределены. (сослаться на несуществующего родителя нельзя, но можно назваться корнем)
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33202573
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer

угу, с вашим выводом согласен

ЗЫ мои цифры, конечно же, не в процентах и avg у меня около 1 т.е. 97% так что они только подтверждают ваш вывод
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33203172
27 понуро бредущих кроликов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321 27 понуро бредущих кроликов Если вы имеете ввиду NULL в поле FK - то смысл FK , который ссылается на несуществующие записи?

целочная ссылочность, однако...
одно другому не противоречит. ссылочная целостность в смысле отсутствия в фк значений, не заданных в ПК (кроме случаев неопределенных родительских записей) - т.е. это частный случай ссылочной целостности. Частный случай - дерево с корнями, чьи родители неопределены. (сослаться на несуществующего родителя нельзя, но можно назваться корнем)

IMHO, FK существует отчасти именно для того, чтобы не допускать неопределенных родительских записей...
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33203337
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
27 понуро бредущих кроликов IMHO, FK существует отчасти именно для того, чтобы не допускать неопределенных родительских записей...
нуда, нуда... Ну дак, известно же что ИМХО=={Имею Мнение -Хй Оспоришь}
Для чего кстати конструкции FK (или релейшена): ...ON DELETE SET NULL ?
Есть разные потребности моделирования. Под них -разные _вариации_ ссылочной целостности. И если существует вариант для "пуристов", то наличие вариантов, не позволяющих иметь несуществующих предков, но позволяющих - неопределенного - очевидно вполне восстребован (уж если производители СУБД внесли его в реализуемые вар-ты).
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33203487
27 понуро бредущих кроликов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot 4321нуда, нуда... Ну дак, известно же что ИМХО=={Имею Мнение -Хй Оспоришь}
[/quot]

IMHO != ИМХО :-))
IMHO = "я ТАК думаю (с) Мимино"
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33203924
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В кадровсой программе возможны NULL
Дата смерти
Дата Увольнения
Дата выхода на пенсию
Имеющиеся правительственные награды
Телефон
И дофига других.

Возможны, но необязательны.
Например, если норамализовать далее (и зачастую это более правильно)
до отдельных таблиц:
Факты смерти
Факты Увольнения
Факты выхода на пенсию
...
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33203959
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник wrote:

> Возможны, но необязательны.
> Например, если норамализовать далее (и зачастую это более правильно)
> до отдельных таблиц:
> Факты смерти
> Факты Увольнения
> Факты выхода на пенсию
угу.. и при добавлении, например "Факта удаления аппендицита" добавлять
табличку... процедуру для обработки... интерфейса... вместо того чтобы
добавить в табличку, скажем "разные факты" новой записи "Факт удаления
аппендицита"....
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33203966
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Роман Дынник wrote:
>
> > Возможны, но необязательны.
> > Например, если норамализовать далее (и зачастую это более правильно)
> > до отдельных таблиц:
> > Факты смерти
> > Факты Увольнения
> > Факты выхода на пенсию
> угу.. и при добавлении, например "Факта удаления аппендицита" добавлять
> табличку... процедуру для обработки... интерфейса... вместо того чтобы
> добавить в табличку, скажем "разные факты" новой записи "Факт удаления
> аппендицита"....
>

и кстати, а если мне понадобится например, жизнеописание чела?
я что, должен буду писать
Код: plaintext
1.
2.
3.
4.
5.
select * from ФактРождения union all
select * from ФактОбучения union all
.......
select * from ФактСмерти
order by date
? некошерно это как-то....
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33204058
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
угу.. и при добавлении, например "Факта удаления аппендицита" добавлять
табличку... процедуру для обработки... интерфейса... вместо того чтобы
добавить в табличку, скажем "разные факты" новой записи "Факт удаления
аппендицита"....

Это уже дело CRUD-слоя раскладывать записи по табличкам, зачастую эту кажущуюся в данном случае сложно процедуру можно сгенерить автоматом на основнии модели данных.
Интерфейс ничем не пострадает, надо просто вспомнить паттерн MVC
Потом в данном случае повышается процент повторного использования кода, не во всех же разработках требуется хранить факт удаления аппендицита, но вот ФИО - везде, таким образом вы выделяете некое общее ядро для различных модулей, которое наращивается в соответствии с требованиями к системе.

и кстати, а если мне понадобится например, жизнеописание чела?
я что, должен буду писать
select * from ФактРождения union all
select * from ФактОбучения union all
.......
select * from ФактСмерти
order by date
некошерно это как-то....

не union all, а обычный join если связь 1-к-1.
Для сложных иерархических объектов - их можно вообще в xml возвращать, далее десериализовывать в бизнес-объект/компонент.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33204138
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник wrote:

>
> Это уже дело CRUD-слоя раскладывать записи по табличкам, зачастую эту
> кажущуюся в данном случае сложно процедуру можно сгенерить автоматом на
> основнии модели данных.
у-ху... т.е. процы генерятся... сами по себе... не проще ли заполнить
справочник типов фактов?
> Интерфейс ничем не пострадает, надо просто вспомнить паттерн MVC
кто такой MVC - не знаю, подозреваю что Microsoft Visual C
Если да, то что, при добавлении нового факта Вы предлагаете
перекомпилить клиента? Или я неправильно понимаю?
> Потом в данном случае повышается процент повторного использования кода,
> не во всех же разработках требуется хранить факт удаления аппендицита,
> но вот ФИО - везде, таким образом вы выделяете некое общее ядро для
> различных модулей, которое наращивается в соответствии с требованиями к
> системе.
>
Да, не везде нужен факт удаления аппендицита, и вот ежели факты хранить
в одной таблице, то наличие или отсутсвие данного факта решительно ни на
кого не повилияет.

> не union all, а обычный join если связь 1-к-1.
> Для сложных иерархических объектов - их можно вообще в xml возвращать,
> далее десериализовывать в бизнес-объект/компонент.

Откуда тут джойн? согласен, рождение-смерть - по одной штуке, а вот
обучение/увольнение/женитьба/развод и прочая - дык их много будит....
и потом... история то вертикально обычно раскладывается, а Вы мне
предлагаете - горизонтально?
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33204355
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
locky
у-ху... т.е. процы генерятся... сами по себе... не проще ли заполнить
справочник типов фактов?

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

кто такой MVC - не знаю, подозреваю что Microsoft Visual C
Если да, то что, при добавлении нового факта Вы предлагаете
перекомпилить клиента? Или я неправильно понимаю?

MVC - это Model View Controller - другими словами отделение данных и управления ими от презентационного уровня (интерфейса)
По поводу же перекомпиляции... думаю вам известно что написание полностью тонко настраиваемого приложения на все случаи - это миф.

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

Если факты храняться в одной таблице - у вас будут NULL-ы - вообщем то это тема данного топика...
другие доводы в пользу отделения я описал выше.

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

структура хранения истории бизнес-объекта определяется на этапе проектирования. т.е. например вы определяете что добавлять в историю при изменении объекта: весь список 1-к-n либо хранить историю для каждой изменяемой записи списка. В общем случае для истории делается поностью дублирующая структура с дополнительными полями типа дата создания/изменения.
И потом, как в вы предлагаете хранить обучение/увольнение/женитьба/развод в одной таблице? нет, ну можно конечно в xml например, но... очень сомнительное решение.
И по поводу join-а при 1-к-n , в mssql ,например, вы можете сделать for xml запрос который и вернет вам всю иерархию бизнес объекта в виде xml.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33204942
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> По-разному бывает выгодно, когда заранее не известно кол-во
> фактов(атрибутов) или список атрибутов часто расширяются в процессе
> эксплуатации - тогда да, выгоднее справочник типов фактов, но в этом
> случае сложнее будет писать запросы поиска по этим трибутам.
Чем есть сложно?
написать запрос вида
Код: plaintext
1.
select * from Facts where FactType='BIRTH'
?
> MVC - это Model View Controller - другими словами отделение данных и
> управления ими от презентационного уровня (интерфейса)
> По поводу же перекомпиляции... думаю вам известно что написание
> полностью тонко настраиваемого приложения на все случаи - это миф.
Ну, совсем тооонко настраиваемое - да, миф... а вот подходящее в 90-95%
случаев.... непросто, но возможно... десятка 3 пиплов с местной тусовки
такое делало (я в том числе)

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

>
> структура хранения истории бизнес-объекта определяется на этапе
> проектирования. т.е. например вы определяете что добавлять в историю при
> изменении объекта: весь список 1-к-n либо хранить историю для каждой
> изменяемой записи списка. В общем случае для истории делается поностью
> дублирующая структура с дополнительными полями типа дата создания/изменения.
> И потом, как в вы предлагаете хранить
> обучение/увольнение/женитьба/развод в одной таблице? нет, ну можно
> конечно в xml например, но... очень сомнительное решение.
Не поняль, о чем йето мы.. но ! Дался всем этот XML, сил моих нету,
лепят куды надоть и не надоть...


Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33211011
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
дорогой locky, видимо мы с вами разговариваем на разных языках
по-этому попытаюсь подвести некое резюме.

Тема NULL-ов уже неоднократно обсуждалась и здесь и на аналогичных ресурсах, и уже давно переросла в разряд идеалогических войн.
NULL или не NULL - вопрос философский, теоритически - без NULL правильнее (в литературе обычно встречаются утверждения что присутствие NULL обычно свидетельствует о потенциальной ошибке проектирования), практически же мало кто доводит систему до такой степени декомпозиции (по лени ли, из удобства или по каким-либо еще причинам) и в практике обычно использование NULL не является большим грехом.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33211859
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KiteГде-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений. Верно ли это утверждение и если верно, то где найти обоснование, что почитать?

В общем, верно. Но это не значит, что если у тебя много NULL-полей, то база спроектирована плохо.

Kite
И может поделитесь рассуждениями и наблюдениями из опыта, насколько мешают NULL значения при эксплуатации БД.


Из опыта - да никак они не мешают.

На самом деле NULL-ы зачем нужны ? Без них тебе нужно было бы вынести все необязательные поля в отдельную таблицу, в пределе - каждое поле в свою, но можно выделить зависимые поля совместно, эти таблицы должны относиться к главной как один-к-ноль_или_один, это усложняет дизайн (ненужные лишние сущности могут появляются, высосанные из пальца), усложняет запросы (join-ить -то надо). Так что NULL-ы - очень полезная вещь. Другое дело, что используя их можно, например, запихать две сущности в одну таблицу , а это - не правильно, ну и все такое прочее.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33211860
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVчтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально.
Не правда.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33211861
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KiteСпасибо всем за высказанные мнения.
А как ведут себя индексы, построенные по полям, содержащим множество значений NULL?

Нормально себя ведут. Как и все другие индексы. Для индекса NULL- просто еще одно значение. Правда, не для всех серверов это верно, у Оракла например, как я знаю, на этот счет мнение не совсем обычное.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33211862
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cat2Kite. Не обращайте внимания. сколько Вам нужно NULL, столько и делайте.
В кадровсой программе возможны NULL
Дата смерти
Дата Увольнения
Дата выхода на пенсию
Имеющиеся правительственные награды
Телефон
И дофига других.


А вот именно эти поля уже под NULL-ом выглядят как дизайн сомнительного качества. Смерти, увольнения и выходы входы можно было бы сделать отдельной таблицей, типа "события в жизни". Телефоны - сам бог повелел в отдельную таблицу, тем более что уже даже во всех мобильных телефонах их для одного товарища принято заводить несколько, а не один.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33212363
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv Смерти , ... можно было бы сделать отдельной таблицей, типа "события в жизни". Телефоны - сам бог повелел в отдельную таблицу, тем более что уже даже во всех мобильных телефонах их для одного товарища принято заводить несколько, а не один.

аха-аха "дайте две" (И отмечать там все клинические смерти пёрсына, покеда окончательно не сдуецца).
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33212381
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321 wrote:
> MasterZiv
> *Смерти*, ... можно было бы сделать отдельной таблицей, типа "события в
> жизни". Телефоны - сам бог повелел в отдельную таблицу, тем более что
> уже даже во всех мобильных телефонах их для одного товарища принято
> заводить несколько, а не один.
>
>
>
> аха-аха "дайте две" (И отмечать там все клинические смерти пёрсына,
> покеда окончательно не сдуецца).
>
да не, смерть она одна в жизни бывает (политики, правда, скажут, что
есть еще политическая смерть). просто хранить одни события тута, а
другие - тама - некошерно, запашештся потом выбирать...

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33214711
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я имел в виду не только для смерти эту таблицу использовать, но и вообще для всех событий в жизни. Там в таблице много было дат, могли бы и догадаться.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215102
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivЯ имел в виду не только для смерти эту таблицу использовать, но и вообще для всех событий в жизни. Там в таблице много было дат, могли бы и догадаться.
Вот тут есть некий момент, который в данном случае не слишком явен, но все ж таки...
А именно, "реальный мир" устроен таким образом, что некое значение является в нем членом множества отношений (естественно я уже перешел с реальности на некую "логическую модель", говоря об отношениях). И существует множество способов расположить эти значения в неких табличных структурах (все остальные отношения получая с помощью выборок по связанным таблицам). Для БД похоронного бюро например отношение "событие жизни" неактуально. Там актуальны только "клиенты" с 2-я заведомо единственными "событиями" - рождением и смертью. Добавлять пару ключей, плюс тип, для ухода от NULL в этом случае мяхко говоря нерационально. И вообще говоря выделять заведомо однократные события (или некие другие заведомо единичные аттрибуты) в некое "однородно" образование типа "сущности "события жизни"" видимо уместно только там, где эти "события" (аттрибуты) интересуют пользователя именно в виде таковой "однородной" в смысле "организующей сущности" выборки.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215179
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321 wrote:
> MasterZiv
> Я имел в виду не только для смерти эту таблицу использовать, но и вообще
> для всех событий в жизни. Там в таблице много было дат, могли бы и
> догадаться.
>
>
> Вот тут есть некий момент, который в данном случае не слишком явен, но
> все ж таки...
> А именно, "реальный мир" устроен таким образом, что некое значение
> является в нем членом множества отношений (естественно я уже перешел с
> реальности на некую "логическую модель", говоря об отношениях). И
> существует множество способов расположить эти значения в неких табличных
> структурах (все остальные отношения получая с помощью выборок по
> связанным таблицам). Для БД похоронного бюро например отношение "событие
> жизни" неактуально. Там актуальны только "клиенты" с 2-я заведомо
> единственными "событиями" - рождением и смертью. Добавлять пару ключей,
> плюс тип, для ухода от NULL в этом случае мяхко говоря нерационально. И
> вообще говоря выделять заведомо однократные события (или некие другие
> заведомо единичные аттрибуты) в некое "однородно" образование типа
> "сущности "события жизни"" видимо уместно только там, где эти "события"
> (аттрибуты) интересуют пользователя именно в виде таковой "однородной" в
> смысле "организующей сущности" выборки.
Кстати, клиентами похоронных бюро являются не покойники, а родственники,
а для них актуальны такие даты как "Дата обращения", "дата захоронения",
"дата оплаты заказа" и т.д....

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215187
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv LSVчтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально.
Не правда.
Для Оракла это правда.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215201
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вообще когда связь между сущностями 1:1, и есть желание иметь хорошую производительность - лучше делать все в одной таблице. Многие базы умею сжимать записи с дефолтными и НУЛЛ значениями. Ввод/Вывод получается меньше.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215225
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lockyКстати, клиентами похоронных бюро являются не покойники, а родственники,
а для них актуальны такие даты как "Дата обращения", "дата захоронения",
"дата оплаты заказа" и т.д....
хммм. Ну этто клиенты несколько другого сорта. Тут вопрос даже не о словах, а об уважении к .... "объектам учета". Давайте таки назовем их как-то иначе, чем "объекты ...". А хотя бы как и "Клиенты", а сродственники перетопчуца - пусть к примеру будут "Контрагентами". И тогда вашу ремарку следует видимо понимать так: "бабло рубят с родственников, и фиксируют их обращения". Но это не причина вести учет "Клиентов" в смысле обслуживаемых боди совместно с учетом "Клиентов" в смысле опустошаемых карманофф. Не так ли?
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215328
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman MasterZiv LSVчтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально.
Не правда.
Для Оракла это правда.
Это - личная проблема вашего оракла.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215359
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321 wrote:
> хммм. Ну этто клиенты несколько другого сорта. Тут вопрос даже не о
> словах, а об уважении к .... "объектам учета". Давайте таки назовем их
> как-то иначе, чем "объекты ...". А хотя бы как и "Клиенты", а
> сродственники перетопчуца - пусть к примеру будут "Контрагентами". И
> тогда вашу ремарку следует видимо понимать так: "бабло рубят с
> родственников, и фиксируют их обращения". Но это не причина вести учет
> "Клиентов" в смысле обслуживаемых боди совместно с учетом "Клиентов" в
> смысле опустошаемых карманофф. Не так ли?

Так, раз уж такая пьянка...
"Боди" - это всего-лишь ммм... сырье для предоставления услуги тем самым
родственникам, которые и являются клиентами, а даты жизни и смерти -
всего один из параметров, написанный в приходной накладной.
Вы когда кота ведете кастрировать - кого в книгу регистрации пишут? "Кот
Васька осьмнадцати лет" или всё-таки "Иванов Петр Васильевич, услуга -
кастрация ейного кота Васьки"?

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215493
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
locky"Боди" - это всего-лишь ммм... сырье для предоставления
ачём споришь, балезный? Если о:
locky кого в книгу регистрации пишут? "Кот
Васька осьмнадцати лет" или всё-таки "Иванов Петр Васильевич, услуга -
кастрация ейного кота Васьки"?то там пишуть и хто, и кого. В разные графы токо.


Если быть точным, то меня интересовал вопрос, нужно ли к боди рисовать отдельную таблицу фактов жизни, когда оно выступает only like a body. Именно на способности неких атрибутов выступать в разном качестве я и говорил. И ничего более. Т.ч. мнение, что "факк-ты" есмь у неких других боди тут как бы показывает отсутствие гляделок или понималки у третьей разновидности боди.
"а он всегда был спорщиком
припрут к стене - откажеца
прошёл он корридорчиком
и кончил
(стенкой, кажеца)"
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215572
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321 wrote:

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


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215656
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
locky Изначально был спор про даты из жизни чела
Поправки:
1."Изначально" был вопро о Null
2. Касательно "событий" вопрос возник в постановки не "жизни чела", а :В кадровсой программе возможны NULL
Дата смерти
Дата Увольнения
Дата выхода на пенсию

так вот, именно в кадровой программе никакой каши из кучи дат приемов и кучи дат увольнений (множественные "факты") вам (хотя и можно, но), по многим причинам (в т.ч простоте ограничений целостности и т.п.), нахрен не надо. надо факты "периоды работы", где не больше 1. даты приема/(пермещения) и 1. даты увольнения(перемещения) на период (и видимо не более 1 должности/1 оклада. - тут, правда можно поразмышлять). Как-то так. А уш даты смерти/рождения должны быть непосредственно в таблице чела. Тут, как грица, могут быть токо 2 мнения - 1 -мое. и 2-е - неправильное


А в "события шиссни челла" оно (то самое "нечто", что мы с разных сторон крутим) превращаеца в некой другой прохрамме, или в некотором другом разрезе. И не нада хрить, шо изначально вопрос так и стоял (в топеге). Его тута не стояло. О чем я и имею вам сообщить.
...
Рейтинг: 0 / 0
Подскажите насчет NULLов в базе
    #33215745
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321 wrote:
> locky
> Изначально был спор про даты из жизни чела

> так вот, именно в кадровой программе никакой каши из кучи дат приемов и
> кучи дат увольнений (множественные "факты") вам (хотя и можно, но), по
> многим причинам (в т.ч простоте ограничений целостности и т.п.), нахрен
> не надо. надо факты "периоды работы", где не больше 1. даты
> приема/(пермещения) и 1. даты увольнения(перемещения) на период (и
> видимо не более 1 должности/1 оклада. - тут, правда можно поразмышлять).
> Как-то так. А уш даты смерти/рождения должны быть непосредственно в
> таблице чела. Тут, как грица, могут быть токо 2 мнения - 1 -мое. и 2-е -
> неправильное
должностей может быть и несколько, совместители, однако...
опять таки декретные отпуска, академические, всевозожные коммандировки и
прочие события, которые могут наступать совместно с периодом работы....
да много чего можно вспомнить.... больничные, кстати...
дык возвращаясь к теме беседы (а то как-то уж далеко отвлеклись).
есть null в базе, нету их - не имеет значения, дело вкуса...

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
53 сообщений из 53, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите насчет NULLов в базе
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]