Обсуждение:Расчет зарплаты повременщиков (постановка)
Насколько правомерен выбор домена DCURRENCY для поля USR$CONTRACTCOEF? Разве этот коэффициент может быть меньше нуля, равен нулю, больше определенного значения? Предлагаю создать свой домен, где наложить соответствующие ограничения:
CHECK((Value IS NULL) OR ((VALUE > 0) AND (VALUE < n))
где коэффициент n определить из нормативно правовой базы.
AndreiK 15:03, 13 December 2006 (CET)
А в чем неправомерность? Если на каждое новое поле создавать свой домен, база будет расти, а разработчики путаться. Дело в том, что для многих коэффициентов используется именно DCURRENCY. С другой стороны, для ЭТОГО КОНКРЕТНОГО КОЭФФИЦИЕНТА мы, допустим, укажем минимальное и максимальное значение (по текущему законодательству он не больше 2). Даже если не думать о моменте, что законодательство имеет свойство меняться, у нас появится домен КОЭФФИЦИЕНТXXX. А сколько этих коэффициентов в зарплате, складе, пользовательских настройках? И у всех разные ограничения. И в именах всех этих доменов наверняка присутствует KOEFF. А потом разработчик, создающий новый коэффициент, недоумевает (может, можно использовать уже существующий домен?!), смотрит по очереди эти домены, и либо создает свой, либо использует DCURRENCY. Получаем:
- много доменов, их названия запутывают разработчика
- каждый из этих доменов подходит только в одном конкретном случае (для конкретного поля конкретной таблицы)
Alexandra.gsoftware 15:37, 13 December 2006 (CET)
Если вы так радикально настроены против создания нового домена, то укажите условия проверки непосредственно для поля. В чем проблема? Кстати, если вы боитесь роста количества доменов, вас не смущает, что сервер создает ДОМЕН на каждое поле, для которого вы укажете встроенный тип? Имеено так: не ищет среди списка доменов подходящий, а создает новый!
Реляционные технологии появились в ответ на рост сложности разрабатываемого ПО. И появились не для того, чтобы усложнять, а для того, чтобы упрощать. FOREIGN KEY, CHECK, NOT NULL, UNIQUE и т.п. -- все эти ограничения позволяют обеспечить логическую целостность данных. Если коэфф. не может быть отрицательным, то мы должны непосредственно для колонки указать это.
AndreiK 15:45, 13 December 2006 (CET)
Кстати, при тестировании, если пользователь сможет ввести отрицательное значение в поле, которое по законодательству должно быть положительным, то это будет считаться ошибкой в ПО.
AndreiK 15:48, 13 December 2006 (CET)
