Обсуждение:Расчет зарплаты повременщиков (постановка)
| Строка 25: | Строка 25: | ||
[[Участник:SYSDBA|AndreiK]] 15:48, 13 December 2006 (CET) | [[Участник:SYSDBA|AndreiK]] 15:48, 13 December 2006 (CET) | ||
| + | ---- | ||
Этот вариант, конечно, лучше: по крайней мере, никто не будет путаться в доменах (на всякие RDB... внимания никто не обращает). Но опять же: мы должны быть точно уверены, что ограничения на этот коэффициент не изменятся в будущем... Я просто пару раз сталкивалась с похожими ситуациями. То в перечисление вдруг добавился еще один элемент, то еще что. Поэтому такие проверки предпочитаю делать в методах. | Этот вариант, конечно, лучше: по крайней мере, никто не будет путаться в доменах (на всякие RDB... внимания никто не обращает). Но опять же: мы должны быть точно уверены, что ограничения на этот коэффициент не изменятся в будущем... Я просто пару раз сталкивалась с похожими ситуациями. То в перечисление вдруг добавился еще один элемент, то еще что. Поэтому такие проверки предпочитаю делать в методах. | ||
| + | --[[Участник:Alexandra.gsoftware|Alexandra.gsoftware]] 15:59, 13 December 2006 (CET) | ||
Версия 14:59, 13 декабря 2006
Насколько правомерен выбор домена 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)
Этот вариант, конечно, лучше: по крайней мере, никто не будет путаться в доменах (на всякие RDB... внимания никто не обращает). Но опять же: мы должны быть точно уверены, что ограничения на этот коэффициент не изменятся в будущем... Я просто пару раз сталкивалась с похожими ситуациями. То в перечисление вдруг добавился еще один элемент, то еще что. Поэтому такие проверки предпочитаю делать в методах. --Alexandra.gsoftware 15:59, 13 December 2006 (CET)
