Обсуждение:Расчет зарплаты повременщиков (постановка)

Текущая версия на 09:47, 14 декабря 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. Получаем:

1. много доменов, их названия запутывают разработчика
2. каждый из этих доменов подходит только в одном конкретном случае (для конкретного поля конкретной таблицы)

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)

Методы, это не лучший вариант по следующим соображениям:

1. Cкорость. Скрипт-функции работают медленно сами по-себе. Загрузка их в скрипт-контрол занимает время.
2. Целостность данных. Проверка в методе действует в одном, конкретном месте для конкретного класса. Что если человек в другой функции поменяет данные с помощью прямого запроса к базе или вообще сделает это не через Гедымин? В этом случае скрипт-функция не сработает, а ограничение на уровне БД будет действовать всегда.
3. Перспектива. Мы сейчас рассматриваем движение в сторону Гедымин 2.0 и интернет технологий. Возможно, нам не удастся подключить макросы, тогда придется конвертировать существующий код. Как вы понимаете, на базу данных это не распространяется. Т.е. использование ограничений на уровне базы существенно уменьшит объем работы в будущем.

AndreiK 17:05, 13 December 2006 (CET)

Коэффициент n можно взять с запасом, например 10 - 15. И сделать стандартный домен. С таким параметром можно создать стандартный домен. Его можно будет использовать не только в подсистеме "Зарплата и кадры", но и в других.

Alexander 08:51, 14 December 2006 (CET)Alexander

Попутный вопрос: если я для поля (не для домена) установлю чеки, то потом могу их изменить и следующей версией настройки перенести клиенту?

AndreiK 10:47, 14 December 2006 (CET)