AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.06.2003, 09:39   #15  
Grizzly is offline
Grizzly
Участник
 
85 / 10 (1) +
Регистрация: 30.01.2003
Адрес: Омск
Цитата:
Изначально опубликовано Nik
Подскажите Grizzli, как эту проблему можно решить "через изменение потребностей пользователя"?
В данном конкретном случае, думаю, никак

В том же сообщении чуть ниже я сказал, что если:
1) объем результирующего множества невелик (не поставит систему "колом" во время выполнения запроса)
2) данный запрос выполняется не часто (не приведет к существенному снижению общей производительности системы)
3) требования к выходной информации изменить нельзя,
то "я бы пристрелил программера, который ради этого стал городить огород, а тем паче менять структуру БД"

Данная задача, как мне кажется, из этой категории

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

Цитата:
Изначально опубликовано Nik
2. Подход к нормализации Персонала и Зарплаты у меня вызывает удивление. С какой целью разработчики ушли от третьей нормальной формы. Буквально везде в полях хранятся вычисляемые значения. Для быстродействия?
Нормализация не догма, а руководство к действию

Иногда существует конфлик между соблюдением требований нормализации и требованиями, предъявляемыми к системе. А любая ИС создается не для того, чтобы демонстрировать свое соответствие математичекис теориям, а для решения конкретных задач. Крис Дейт в своем классическом труде "Руководство по реляционной СУБД DB2" на эту тему сказал: "Принципы нормализации рекомендуют руководствоваться критерием "один факт в одном месте"; но иногда есть существенные причины для того, чтобы иметь два факта в одном месте или один факт в двух местах". Использование принципов нормализации в РСУБД в некоторой степени было призвано оптимизировать операции по модификации (создание, обновление, удаление) за счет сокращения избыточности данных. Но иногда избыточность бывает полезна с точки зрения оптимизации операций по выборке.

Все относительно...

Кроме того, даже атомарность атрибута, о которой говорил Lazy_Tiger, вещь тоже достаточно относительная и определяется выполняемыми над ним операциями. Вот с одним из таких проявлений относительности атомарности атрибута Вы и столкнулись (иногда дату нужно рассматривать как набор из трех атрибутов, но чаще удобнее как единое целое). И, на мой взгляд, никакого противоречия с требованиями 1nf здесь нет.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
триггер OnLookup поля формы Alex_V NAV: Программирование 4 14.07.2004 15:12
Navision Attain через Citrix Alex_V NAV: Администрирование 2 15.12.2003 17:43
Переход на Navision Attain Makc_1 NAV: Прочие вопросы 3 30.07.2003 14:36
Изменение длины полей в Attain'e Real NAV: Программирование 11 10.07.2003 09:55
Attain. Как сделать вычисляемые поля на форме? Evgeniy NAV: Программирование 3 04.04.2003 07:24

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 23:16.