|
|
#15 |
|
Участник
|
Цитата:
Изначально опубликовано Nik
Подскажите Grizzli, как эту проблему можно решить "через изменение потребностей пользователя"? ![]() В том же сообщении чуть ниже я сказал, что если: 1) объем результирующего множества невелик (не поставит систему "колом" во время выполнения запроса) 2) данный запрос выполняется не часто (не приведет к существенному снижению общей производительности системы) 3) требования к выходной информации изменить нельзя, то "я бы пристрелил программера, который ради этого стал городить огород, а тем паче менять структуру БД" ![]() Данная задача, как мне кажется, из этой категории ![]() Но поверьте мне, бОльшей частью "требования пользователя" определяются не действительнымит потребностями, а привычками работы либо с предшествующей системой, либо вручную. В то время как аналитики даже не пытаются выяснить истинные причины таких требований. Цитата:
Изначально опубликовано Nik
2. Подход к нормализации Персонала и Зарплаты у меня вызывает удивление. С какой целью разработчики ушли от третьей нормальной формы. Буквально везде в полях хранятся вычисляемые значения. Для быстродействия? Иногда существует конфлик между соблюдением требований нормализации и требованиями, предъявляемыми к системе. А любая ИС создается не для того, чтобы демонстрировать свое соответствие математичекис теориям, а для решения конкретных задач. Крис Дейт в своем классическом труде "Руководство по реляционной СУБД DB2" на эту тему сказал: "Принципы нормализации рекомендуют руководствоваться критерием "один факт в одном месте"; но иногда есть существенные причины для того, чтобы иметь два факта в одном месте или один факт в двух местах". Использование принципов нормализации в РСУБД в некоторой степени было призвано оптимизировать операции по модификации (создание, обновление, удаление) за счет сокращения избыточности данных. Но иногда избыточность бывает полезна с точки зрения оптимизации операций по выборке. Все относительно... Кроме того, даже атомарность атрибута, о которой говорил Lazy_Tiger, вещь тоже достаточно относительная и определяется выполняемыми над ним операциями. Вот с одним из таких проявлений относительности атомарности атрибута Вы и столкнулись (иногда дату нужно рассматривать как набор из трех атрибутов, но чаще удобнее как единое целое). И, на мой взгляд, никакого противоречия с требованиями 1nf здесь нет.
|
|
|
|
|
Похожие темы
|
||||
| Тема | Ответов | |||
| триггер OnLookup поля формы | 4 | |||
| Navision Attain через Citrix | 2 | |||
| Переход на Navision Attain | 3 | |||
| Изменение длины полей в Attain'e | 11 | |||
| Attain. Как сделать вычисляемые поля на форме? | 3 | |||
|