Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Где-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений. Верно ли это утверждение и если верно, то где найти обоснование, что почитать? И может поделитесь рассуждениями и наблюдениями из опыта, насколько мешают NULL значения при эксплуатации БД. Спасибо заранее... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 19:37 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Kite wrote: > Где-то встречала выражение, что хорошо спроектированная БД не должна > содержать большого количества NULL значений. Верно ли это утверждение и > если верно, то где найти обоснование, что почитать? http://www.dbdebunk.com/page/page/1706744.htm Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 19:42 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
KiteГде-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений. На мой взгляд, все определяется здравым смыслом. А здравый смысл подсказывает что в реальной системе очень большое количество полей может быть необязательно к заполнению. Простейший пример - справочник партнеров который содержит кроме наменования инн, оконх, окпо, егрн значения которых в большинстве случаев неизвестно. По крайней мере про старые версии Sybase и MS SQL говорили что сервер более оптимально располагает на страницах NOT NULL данные, что приводит к небольшому ускорению дисковых операций. Но по моему не стоит специально обращать внимание на это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 10:20 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Простейший пример - справочник партнеров который содержит кроме наменования инн, оконх, окпо, егрн значения которых в большинстве случаев неизвестно.Это, увы не пример удачной системы. А если появятся ещё 5 реквизитов (например, введут к-л новые требования) ? Будете поля добавлять ? Впрочем, некоторое кол-во нулов это вполне нормальная ситуация. Главное, чтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 10:33 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
[quot LSVЭто, увы не пример удачной системы. А если появятся ещё 5 реквизитов (например, введут к-л новые требования) ? Будете поля добавлять? [/quot] Угу, иначе кто мне деньги платить будет за поддержку ;) А по поводу хранения реквизитов в отдельной таблице или в основной, достаточно много рассуждений на этом форуме. Скажу сразу у нас в системе реализованы оба подхода. Все что входит в "анкету" лица сидит в основной таблице, все доп. данные в динамических классификаторах к анкете. Как обычно всегда требуется баланс между удобством и производительностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 10:57 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Дейт с Давином с самого начала были против null'ов. И основной упор делали во-первых на то что в современных СУБД под null понимается 2 разных понятия - собственно null и unk (unknown)... во-вторых на сложности с формулированием предиката для отношения содержащего null С первым я полностью согласен, со вторым где-то на 30% ;) Правда в реальных системах null или какая-либо константа его заменяющая - это меньшее из зол ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 11:16 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
LSV[quot ]Простейший пример - справочник партнеров который содержит кроме наменования инн, оконх, окпо, егрн значения которых в большинстве случаев неизвестно.Это, увы не пример удачной системы. А если появятся ещё 5 реквизитов (например, введут к-л новые требования) ? Будете поля добавлять ? А как по-другому? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 11:29 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
KiteГде-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений. Верно ли это утверждение и если верно, то где найти обоснование, что почитать? И может поделитесь рассуждениями и наблюдениями из опыта, насколько мешают NULL значения при эксплуатации БД. Спасибо заранее...Я бы сказал немного по-другому: верно, что хорошо нормализованная БД не должна содержать большого количества NULL значений. Но хорошо спроектированная и хорошо нормализованная БД - далеко не всегда тождественные понятия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 12:22 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Спасибо всем за высказанные мнения. А как ведут себя индексы, построенные по полям, содержащим множество значений NULL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 13:22 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Полностью избавленная от null-ов БД - полностью декомпозированная - для каждого атрибута своя таблица ))))) Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 14:58 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Kite К сожалению, поведение индексов разнится в зависимости от СУБД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 12:53 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Kite. Не обращайте внимания. сколько Вам нужно NULL, столько и делайте. В кадровсой программе возможны NULL Дата смерти Дата Увольнения Дата выхода на пенсию Имеющиеся правительственные награды Телефон И дофига других. Типа размера обуви, которая нужна только тем, кто имеет право на на выдачу обуви как спецодежды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:21 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
KiteА как ведут себя индексы, построенные по полям, содержащим множество значений NULL? Значение NULL в подавляющем большинстве случаев низкоселективно, а следовательно использование b-индекса для выбора записей по условию field is null будет неэффективным. В принципе я вижу три варианта: обрабатывать null по общей схеме, как и любое другое значение исключать null записи из индекса хранить null в некотором особом списке Третий из них - не знаю, работает ли где-то, и несколько странен. Он был бы удобен, но непонятно как обобщить это решение для индекса по нескольким полям. Вторым подходом пользуется Oracle; вроде упоминали, что такая настройка есть в Access, может и еще где-то. Таким образом уменьшаются потери на хранение ненужных данных в индексе, но индекс становится менее применим (не может быть использован в некоторых запросах, например select count). Первый - вроде наиболее прост в понимании :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 18:19 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Значение NULL в подавляющем большинстве случаев низкоселективно, как раз правота этого утверждения сильно зависит от того как эту БД проектировали... можно сделать и высокоселективным ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 19:02 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
исключать null записи из индекса Так работают многие промышленные СУБД. Точно знаю про MSSQL и Oracle. Поэтому выражение: WHERE MyField is null низкопроизводительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 19:57 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
funikovyuriЗначение NULL в подавляющем большинстве случаев низкоселективно, как раз правота этого утверждения сильно зависит от того как эту БД проектировали... можно сделать и высокоселективным ;) Читаем: "... в подавляющем большинстве". Да, если задаться целью, можно спроектировать базу, в которой это утверждение не выполняется. Согласен, даже сам могу такое сделать :) Собственно я даже заранее согласен с тем, что это статистическое утверждение, причем по моей личной статистике. И если кто-нибудь расскажет, на каких задачах он получает резко другие показатели, я с большим интересом его послушаю. Что касается баз, с которыми я имею дело прямо сейчас, то... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 16:20 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 16:43 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
У меня вот так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Но за примером высокой селективности далеко ходить также не надо. Например, взять так часто используемое отношение наследования и одно из возможных его представлений в РМД в виде одной таблицы на всю иерархию. Таблица должна содержать объединение всех атрибутов всех сущностей связанных наследованием... Далее достаточно чтобы какой-либо класс желательно выше по иерархии имел наибольшее количество объектов-записей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 19:13 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
funikovyuriУ меня вот так Хм. А приведенные Вами цифры - все в процентах? (спрашиваю, поскольку у Вас из селекта выпало умножение на сто, а сами цифры... пожалуй что неожиданные в другую сторону, прежде всего дико низкое среднее значение). funikovyuriНо за примером высокой селективности далеко ходить также не надо. Вопрос в частоте таких примеров. Как видите, у меня поиск тоже нашел табличку, где есть null-ы, но их количество ничтожно. Вопрос - как часто такое вcтречается и как часто в таких таблицах нужно искать по is null. Когда такое происходит - меня не особо напрягает создать соответствующий "более хитрый" индекс. А un mass все же null прискорбно неселективен :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 14:02 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Есть понятие внешнего ключа (FK). Если NULL не будет, какое значение должно содержать поле внешнего ключа в записи, не имеющее связи с подчиненной сущностью? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 17:23 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Slider_spb Боюсь, я не понял связи Вашего вопроса с темой и предыдущим обсуждением. Не расшифруете, что Вы имели в виду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 17:38 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Slider_spbЕсть понятие внешнего ключа (FK). Если NULL не будет, какое значение должно содержать поле внешнего ключа в записи, не имеющее связи с подчиненной сущностью? FK подразумевает связь с первичным ключем, скажем, справочной таблицы. А NULL в PK - эт , мягко говоря, странно... Если вы имеете ввиду NULL в поле FK - то смысл FK , который ссылается на несуществующие записи? целочная ссылочность, однако... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 18:30 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
27 понуро бредущих кроликов Если вы имеете ввиду NULL в поле FK - то смысл FK , который ссылается на несуществующие записи? целочная ссылочность, однако... одно другому не противоречит. ссылочная целостность в смысле отсутствия в фк значений, не заданных в ПК (кроме случаев неопределенных родительских записей) - т.е. это частный случай ссылочной целостности. Частный случай - дерево с корнями, чьи родители неопределены. (сослаться на несуществующего родителя нельзя, но можно назваться корнем) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 18:43 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
softwarer угу, с вашим выводом согласен ЗЫ мои цифры, конечно же, не в процентах и avg у меня около 1 т.е. 97% так что они только подтверждают ваш вывод ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 18:47 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
4321 27 понуро бредущих кроликов Если вы имеете ввиду NULL в поле FK - то смысл FK , который ссылается на несуществующие записи? целочная ссылочность, однако... одно другому не противоречит. ссылочная целостность в смысле отсутствия в фк значений, не заданных в ПК (кроме случаев неопределенных родительских записей) - т.е. это частный случай ссылочной целостности. Частный случай - дерево с корнями, чьи родители неопределены. (сослаться на несуществующего родителя нельзя, но можно назваться корнем) IMHO, FK существует отчасти именно для того, чтобы не допускать неопределенных родительских записей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 09:47 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
27 понуро бредущих кроликов IMHO, FK существует отчасти именно для того, чтобы не допускать неопределенных родительских записей... нуда, нуда... Ну дак, известно же что ИМХО=={Имею Мнение -Хй Оспоришь} Для чего кстати конструкции FK (или релейшена): ...ON DELETE SET NULL ? Есть разные потребности моделирования. Под них -разные _вариации_ ссылочной целостности. И если существует вариант для "пуристов", то наличие вариантов, не позволяющих иметь несуществующих предков, но позволяющих - неопределенного - очевидно вполне восстребован (уж если производители СУБД внесли его в реализуемые вар-ты). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 10:29 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
[quot 4321нуда, нуда... Ну дак, известно же что ИМХО=={Имею Мнение -Хй Оспоришь} [/quot] IMHO != ИМХО :-)) IMHO = "я ТАК думаю (с) Мимино" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 11:09 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
В кадровсой программе возможны NULL Дата смерти Дата Увольнения Дата выхода на пенсию Имеющиеся правительственные награды Телефон И дофига других. Возможны, но необязательны. Например, если норамализовать далее (и зачастую это более правильно) до отдельных таблиц: Факты смерти Факты Увольнения Факты выхода на пенсию ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 12:47 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Роман Дынник wrote: > Возможны, но необязательны. > Например, если норамализовать далее (и зачастую это более правильно) > до отдельных таблиц: > Факты смерти > Факты Увольнения > Факты выхода на пенсию угу.. и при добавлении, например "Факта удаления аппендицита" добавлять табличку... процедуру для обработки... интерфейса... вместо того чтобы добавить в табличку, скажем "разные факты" новой записи "Факт удаления аппендицита".... Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 12:54 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
> Роман Дынник wrote: > > > Возможны, но необязательны. > > Например, если норамализовать далее (и зачастую это более правильно) > > до отдельных таблиц: > > Факты смерти > > Факты Увольнения > > Факты выхода на пенсию > угу.. и при добавлении, например "Факта удаления аппендицита" добавлять > табличку... процедуру для обработки... интерфейса... вместо того чтобы > добавить в табличку, скажем "разные факты" новой записи "Факт удаления > аппендицита".... > и кстати, а если мне понадобится например, жизнеописание чела? я что, должен буду писать Код: plaintext 1. 2. 3. 4. 5. Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 12:56 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
угу.. и при добавлении, например "Факта удаления аппендицита" добавлять табличку... процедуру для обработки... интерфейса... вместо того чтобы добавить в табличку, скажем "разные факты" новой записи "Факт удаления аппендицита".... Это уже дело CRUD-слоя раскладывать записи по табличкам, зачастую эту кажущуюся в данном случае сложно процедуру можно сгенерить автоматом на основнии модели данных. Интерфейс ничем не пострадает, надо просто вспомнить паттерн MVC Потом в данном случае повышается процент повторного использования кода, не во всех же разработках требуется хранить факт удаления аппендицита, но вот ФИО - везде, таким образом вы выделяете некое общее ядро для различных модулей, которое наращивается в соответствии с требованиями к системе. и кстати, а если мне понадобится например, жизнеописание чела? я что, должен буду писать select * from ФактРождения union all select * from ФактОбучения union all ....... select * from ФактСмерти order by date некошерно это как-то.... не union all, а обычный join если связь 1-к-1. Для сложных иерархических объектов - их можно вообще в xml возвращать, далее десериализовывать в бизнес-объект/компонент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 13:16 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Роман Дынник wrote: > > Это уже дело CRUD-слоя раскладывать записи по табличкам, зачастую эту > кажущуюся в данном случае сложно процедуру можно сгенерить автоматом на > основнии модели данных. у-ху... т.е. процы генерятся... сами по себе... не проще ли заполнить справочник типов фактов? > Интерфейс ничем не пострадает, надо просто вспомнить паттерн MVC кто такой MVC - не знаю, подозреваю что Microsoft Visual C Если да, то что, при добавлении нового факта Вы предлагаете перекомпилить клиента? Или я неправильно понимаю? > Потом в данном случае повышается процент повторного использования кода, > не во всех же разработках требуется хранить факт удаления аппендицита, > но вот ФИО - везде, таким образом вы выделяете некое общее ядро для > различных модулей, которое наращивается в соответствии с требованиями к > системе. > Да, не везде нужен факт удаления аппендицита, и вот ежели факты хранить в одной таблице, то наличие или отсутсвие данного факта решительно ни на кого не повилияет. > не union all, а обычный join если связь 1-к-1. > Для сложных иерархических объектов - их можно вообще в xml возвращать, > далее десериализовывать в бизнес-объект/компонент. Откуда тут джойн? согласен, рождение-смерть - по одной штуке, а вот обучение/увольнение/женитьба/развод и прочая - дык их много будит.... и потом... история то вертикально обычно раскладывается, а Вы мне предлагаете - горизонтально? Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 13:37 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
locky у-ху... т.е. процы генерятся... сами по себе... не проще ли заполнить справочник типов фактов? По-разному бывает выгодно, когда заранее не известно кол-во фактов(атрибутов) или список атрибутов часто расширяются в процессе эксплуатации - тогда да, выгоднее справочник типов фактов, но в этом случае сложнее будет писать запросы поиска по этим трибутам. кто такой MVC - не знаю, подозреваю что Microsoft Visual C Если да, то что, при добавлении нового факта Вы предлагаете перекомпилить клиента? Или я неправильно понимаю? MVC - это Model View Controller - другими словами отделение данных и управления ими от презентационного уровня (интерфейса) По поводу же перекомпиляции... думаю вам известно что написание полностью тонко настраиваемого приложения на все случаи - это миф. Да, не везде нужен факт удаления аппендицита, и вот ежели факты хранить в одной таблице, то наличие или отсутсвие данного факта решительно ни на кого не повилияет. Если факты храняться в одной таблице - у вас будут NULL-ы - вообщем то это тема данного топика... другие доводы в пользу отделения я описал выше. Откуда тут джойн? согласен, рождение-смерть - по одной штуке, а вот обучение/увольнение/женитьба/развод и прочая - дык их много будит.... и потом... история то вертикально обычно раскладывается, а Вы мне предлагаете - горизонтально? структура хранения истории бизнес-объекта определяется на этапе проектирования. т.е. например вы определяете что добавлять в историю при изменении объекта: весь список 1-к-n либо хранить историю для каждой изменяемой записи списка. В общем случае для истории делается поностью дублирующая структура с дополнительными полями типа дата создания/изменения. И потом, как в вы предлагаете хранить обучение/увольнение/женитьба/развод в одной таблице? нет, ну можно конечно в xml например, но... очень сомнительное решение. И по поводу join-а при 1-к-n , в mssql ,например, вы можете сделать for xml запрос который и вернет вам всю иерархию бизнес объекта в виде xml. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 14:45 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
> По-разному бывает выгодно, когда заранее не известно кол-во > фактов(атрибутов) или список атрибутов часто расширяются в процессе > эксплуатации - тогда да, выгоднее справочник типов фактов, но в этом > случае сложнее будет писать запросы поиска по этим трибутам. Чем есть сложно? написать запрос вида Код: plaintext 1. > MVC - это Model View Controller - другими словами отделение данных и > управления ими от презентационного уровня (интерфейса) > По поводу же перекомпиляции... думаю вам известно что написание > полностью тонко настраиваемого приложения на все случаи - это миф. Ну, совсем тооонко настраиваемое - да, миф... а вот подходящее в 90-95% случаев.... непросто, но возможно... десятка 3 пиплов с местной тусовки такое делало (я в том числе) > Если факты храняться в одной таблице - у вас будут NULL-ы - вообщем то > это тема данного топика... > другие доводы в пользу отделения я описал выше. Откель наллы, милейший? нету факта женитьбы - нету записи в табличке фактов, и всего делов.... > > структура хранения истории бизнес-объекта определяется на этапе > проектирования. т.е. например вы определяете что добавлять в историю при > изменении объекта: весь список 1-к-n либо хранить историю для каждой > изменяемой записи списка. В общем случае для истории делается поностью > дублирующая структура с дополнительными полями типа дата создания/изменения. > И потом, как в вы предлагаете хранить > обучение/увольнение/женитьба/развод в одной таблице? нет, ну можно > конечно в xml например, но... очень сомнительное решение. Не поняль, о чем йето мы.. но ! Дался всем этот XML, сил моих нету, лепят куды надоть и не надоть... Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 18:46 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
дорогой locky, видимо мы с вами разговариваем на разных языках по-этому попытаюсь подвести некое резюме. Тема NULL-ов уже неоднократно обсуждалась и здесь и на аналогичных ресурсах, и уже давно переросла в разряд идеалогических войн. NULL или не NULL - вопрос философский, теоритически - без NULL правильнее (в литературе обычно встречаются утверждения что присутствие NULL обычно свидетельствует о потенциальной ошибке проектирования), практически же мало кто доводит систему до такой степени декомпозиции (по лени ли, из удобства или по каким-либо еще причинам) и в практике обычно использование NULL не является большим грехом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 16:35 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
KiteГде-то встречала выражение, что хорошо спроектированная БД не должна содержать большого количества NULL значений. Верно ли это утверждение и если верно, то где найти обоснование, что почитать? В общем, верно. Но это не значит, что если у тебя много NULL-полей, то база спроектирована плохо. Kite И может поделитесь рассуждениями и наблюдениями из опыта, насколько мешают NULL значения при эксплуатации БД. Из опыта - да никак они не мешают. На самом деле NULL-ы зачем нужны ? Без них тебе нужно было бы вынести все необязательные поля в отдельную таблицу, в пределе - каждое поле в свою, но можно выделить зависимые поля совместно, эти таблицы должны относиться к главной как один-к-ноль_или_один, это усложняет дизайн (ненужные лишние сущности могут появляются, высосанные из пальца), усложняет запросы (join-ить -то надо). Так что NULL-ы - очень полезная вещь. Другое дело, что используя их можно, например, запихать две сущности в одну таблицу , а это - не правильно, ну и все такое прочее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 03:26 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
LSVчтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально. Не правда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 03:26 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
KiteСпасибо всем за высказанные мнения. А как ведут себя индексы, построенные по полям, содержащим множество значений NULL? Нормально себя ведут. Как и все другие индексы. Для индекса NULL- просто еще одно значение. Правда, не для всех серверов это верно, у Оракла например, как я знаю, на этот счет мнение не совсем обычное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 03:29 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Cat2Kite. Не обращайте внимания. сколько Вам нужно NULL, столько и делайте. В кадровсой программе возможны NULL Дата смерти Дата Увольнения Дата выхода на пенсию Имеющиеся правительственные награды Телефон И дофига других. А вот именно эти поля уже под NULL-ом выглядят как дизайн сомнительного качества. Смерти, увольнения и выходы входы можно было бы сделать отдельной таблицей, типа "события в жизни". Телефоны - сам бог повелел в отдельную таблицу, тем более что уже даже во всех мобильных телефонах их для одного товарища принято заводить несколько, а не один. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 03:33 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
MasterZiv Смерти , ... можно было бы сделать отдельной таблицей, типа "события в жизни". Телефоны - сам бог повелел в отдельную таблицу, тем более что уже даже во всех мобильных телефонах их для одного товарища принято заводить несколько, а не один. аха-аха "дайте две" (И отмечать там все клинические смерти пёрсына, покеда окончательно не сдуецца). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 11:14 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
4321 wrote: > MasterZiv > *Смерти*, ... можно было бы сделать отдельной таблицей, типа "события в > жизни". Телефоны - сам бог повелел в отдельную таблицу, тем более что > уже даже во всех мобильных телефонах их для одного товарища принято > заводить несколько, а не один. > > > > аха-аха "дайте две" (И отмечать там все клинические смерти пёрсына, > покеда окончательно не сдуецца). > да не, смерть она одна в жизни бывает (политики, правда, скажут, что есть еще политическая смерть). просто хранить одни события тута, а другие - тама - некошерно, запашештся потом выбирать... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 11:21 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
Я имел в виду не только для смерти эту таблицу использовать, но и вообще для всех событий в жизни. Там в таблице много было дат, могли бы и догадаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 00:26 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
MasterZivЯ имел в виду не только для смерти эту таблицу использовать, но и вообще для всех событий в жизни. Там в таблице много было дат, могли бы и догадаться. Вот тут есть некий момент, который в данном случае не слишком явен, но все ж таки... А именно, "реальный мир" устроен таким образом, что некое значение является в нем членом множества отношений (естественно я уже перешел с реальности на некую "логическую модель", говоря об отношениях). И существует множество способов расположить эти значения в неких табличных структурах (все остальные отношения получая с помощью выборок по связанным таблицам). Для БД похоронного бюро например отношение "событие жизни" неактуально. Там актуальны только "клиенты" с 2-я заведомо единственными "событиями" - рождением и смертью. Добавлять пару ключей, плюс тип, для ухода от NULL в этом случае мяхко говоря нерационально. И вообще говоря выделять заведомо однократные события (или некие другие заведомо единичные аттрибуты) в некое "однородно" образование типа "сущности "события жизни"" видимо уместно только там, где эти "события" (аттрибуты) интересуют пользователя именно в виде таковой "однородной" в смысле "организующей сущности" выборки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 11:06 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
4321 wrote: > MasterZiv > Я имел в виду не только для смерти эту таблицу использовать, но и вообще > для всех событий в жизни. Там в таблице много было дат, могли бы и > догадаться. > > > Вот тут есть некий момент, который в данном случае не слишком явен, но > все ж таки... > А именно, "реальный мир" устроен таким образом, что некое значение > является в нем членом множества отношений (естественно я уже перешел с > реальности на некую "логическую модель", говоря об отношениях). И > существует множество способов расположить эти значения в неких табличных > структурах (все остальные отношения получая с помощью выборок по > связанным таблицам). Для БД похоронного бюро например отношение "событие > жизни" неактуально. Там актуальны только "клиенты" с 2-я заведомо > единственными "событиями" - рождением и смертью. Добавлять пару ключей, > плюс тип, для ухода от NULL в этом случае мяхко говоря нерационально. И > вообще говоря выделять заведомо однократные события (или некие другие > заведомо единичные аттрибуты) в некое "однородно" образование типа > "сущности "события жизни"" видимо уместно только там, где эти "события" > (аттрибуты) интересуют пользователя именно в виде таковой "однородной" в > смысле "организующей сущности" выборки. Кстати, клиентами похоронных бюро являются не покойники, а родственники, а для них актуальны такие даты как "Дата обращения", "дата захоронения", "дата оплаты заказа" и т.д.... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 11:28 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
MasterZiv LSVчтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально. Не правда. Для Оракла это правда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 11:30 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
вообще когда связь между сущностями 1:1, и есть желание иметь хорошую производительность - лучше делать все в одной таблице. Многие базы умею сжимать записи с дефолтными и НУЛЛ значениями. Ввод/Вывод получается меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 11:33 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
lockyКстати, клиентами похоронных бюро являются не покойники, а родственники, а для них актуальны такие даты как "Дата обращения", "дата захоронения", "дата оплаты заказа" и т.д.... хммм. Ну этто клиенты несколько другого сорта. Тут вопрос даже не о словах, а об уважении к .... "объектам учета". Давайте таки назовем их как-то иначе, чем "объекты ...". А хотя бы как и "Клиенты", а сродственники перетопчуца - пусть к примеру будут "Контрагентами". И тогда вашу ремарку следует видимо понимать так: "бабло рубят с родственников, и фиксируют их обращения". Но это не причина вести учет "Клиентов" в смысле обслуживаемых боди совместно с учетом "Клиентов" в смысле опустошаемых карманофф. Не так ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 11:39 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
gardenman MasterZiv LSVчтоб в запросах проверок на НУЛЛ было поменьше, т.к. в этом случае сервера работают неоптимально. Не правда. Для Оракла это правда. Это - личная проблема вашего оракла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 12:10 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
4321 wrote: > хммм. Ну этто клиенты несколько другого сорта. Тут вопрос даже не о > словах, а об уважении к .... "объектам учета". Давайте таки назовем их > как-то иначе, чем "объекты ...". А хотя бы как и "Клиенты", а > сродственники перетопчуца - пусть к примеру будут "Контрагентами". И > тогда вашу ремарку следует видимо понимать так: "бабло рубят с > родственников, и фиксируют их обращения". Но это не причина вести учет > "Клиентов" в смысле обслуживаемых боди совместно с учетом "Клиентов" в > смысле опустошаемых карманофф. Не так ли? Так, раз уж такая пьянка... "Боди" - это всего-лишь ммм... сырье для предоставления услуги тем самым родственникам, которые и являются клиентами, а даты жизни и смерти - всего один из параметров, написанный в приходной накладной. Вы когда кота ведете кастрировать - кого в книгу регистрации пишут? "Кот Васька осьмнадцати лет" или всё-таки "Иванов Петр Васильевич, услуга - кастрация ейного кота Васьки"? -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 12:21 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
locky"Боди" - это всего-лишь ммм... сырье для предоставления ачём споришь, балезный? Если о: locky кого в книгу регистрации пишут? "Кот Васька осьмнадцати лет" или всё-таки "Иванов Петр Васильевич, услуга - кастрация ейного кота Васьки"?то там пишуть и хто, и кого. В разные графы токо. Если быть точным, то меня интересовал вопрос, нужно ли к боди рисовать отдельную таблицу фактов жизни, когда оно выступает only like a body. Именно на способности неких атрибутов выступать в разном качестве я и говорил. И ничего более. Т.ч. мнение, что "факк-ты" есмь у неких других боди тут как бы показывает отсутствие гляделок или понималки у третьей разновидности боди. "а он всегда был спорщиком припрут к стене - откажеца прошёл он корридорчиком и кончил (стенкой, кажеца)" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 13:18 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
4321 wrote: Так, от токо без рук! Изначально был спор про даты из жизни чела, коих фактов много быть может. Постепенно скатилось всё к факту смерти, похоронному бюро... дык не о похоронном бюро то изначально говорили, где боди есть всего ящик с заранее определенными параметрами (партия товара, так сказать) а о фиксации заранее неизвестного набора заранее неизвестных дат. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 13:45 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
locky Изначально был спор про даты из жизни чела Поправки: 1."Изначально" был вопро о Null 2. Касательно "событий" вопрос возник в постановки не "жизни чела", а :В кадровсой программе возможны NULL Дата смерти Дата Увольнения Дата выхода на пенсию так вот, именно в кадровой программе никакой каши из кучи дат приемов и кучи дат увольнений (множественные "факты") вам (хотя и можно, но), по многим причинам (в т.ч простоте ограничений целостности и т.п.), нахрен не надо. надо факты "периоды работы", где не больше 1. даты приема/(пермещения) и 1. даты увольнения(перемещения) на период (и видимо не более 1 должности/1 оклада. - тут, правда можно поразмышлять). Как-то так. А уш даты смерти/рождения должны быть непосредственно в таблице чела. Тут, как грица, могут быть токо 2 мнения - 1 -мое. и 2-е - неправильное А в "события шиссни челла" оно (то самое "нечто", что мы с разных сторон крутим) превращаеца в некой другой прохрамме, или в некотором другом разрезе. И не нада хрить, шо изначально вопрос так и стоял (в топеге). Его тута не стояло. О чем я и имею вам сообщить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 14:08 |
|
||
|
Подскажите насчет NULLов в базе
|
|||
|---|---|---|---|
|
#18+
4321 wrote: > locky > Изначально был спор про даты из жизни чела > так вот, именно в кадровой программе никакой каши из кучи дат приемов и > кучи дат увольнений (множественные "факты") вам (хотя и можно, но), по > многим причинам (в т.ч простоте ограничений целостности и т.п.), нахрен > не надо. надо факты "периоды работы", где не больше 1. даты > приема/(пермещения) и 1. даты увольнения(перемещения) на период (и > видимо не более 1 должности/1 оклада. - тут, правда можно поразмышлять). > Как-то так. А уш даты смерти/рождения должны быть непосредственно в > таблице чела. Тут, как грица, могут быть токо 2 мнения - 1 -мое. и 2-е - > неправильное должностей может быть и несколько, совместители, однако... опять таки декретные отпуска, академические, всевозожные коммандировки и прочие события, которые могут наступать совместно с периодом работы.... да много чего можно вспомнить.... больничные, кстати... дык возвращаясь к теме беседы (а то как-то уж далеко отвлеклись). есть null в базе, нету их - не имеет значения, дело вкуса... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2005, 14:41 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1545724]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
106ms |
get tp. blocked users: |
2ms |
| others: | 259ms |
| total: | 442ms |

| 0 / 0 |
