Обсуждение:Расчет зарплаты повременщиков (постановка)
SYSDBA (обсуждение | вклад) (→А в чем неправомерность?) |
|||
| Строка 11: | Строка 11: | ||
# много доменов, их названия запутывают разработчика | # много доменов, их названия запутывают разработчика | ||
# каждый из этих доменов подходит только в одном конкретном случае (для конкретного поля конкретной таблицы) | # каждый из этих доменов подходит только в одном конкретном случае (для конкретного поля конкретной таблицы) | ||
| − | + | [[Участник:Alexandra.gsoftware|Alexandra.gsoftware]] 15:37, 13 December 2006 (CET) | |
| + | |||
| + | ---- | ||
| + | Если вы так радикально настроены против создания нового домена, то укажите условия проверки непосредственно для поля. В чем проблема? | ||
| + | Кстати, если вы боитесь роста количества доменов, вас не смущает, что сервер создает ДОМЕН на каждое поле, для которого вы укажете встроенный тип? Имеено так: не ищет среди списка доменов подходящий, а создает новый! | ||
| + | |||
| + | Реляционные технологии появились в ответ на рост сложности разрабатываемого ПО. И появились не для того, чтобы усложнять, а для того, чтобы упрощать. FOREIGN KEY, CHECK, NOT NULL, UNIQUE и т.п. -- все эти ограничения позволяют обеспечить логическую целостность данных. Если коэфф. не может быть отрицательным, то мы должны непосредственно для колонки указать это. | ||
| + | |||
| + | [[Участник:SYSDBA|AndreiK]] 15:45, 13 December 2006 (CET) | ||
Версия 14:45, 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)
