Кейс такой – есть услуга, которая оказывается клиенту. В зависимости от, допустим, количества «попугаев», потребленных клиентом, стоимость может плясать. Шкала эта нелинейная и произвольная, причем для каждого клиента может быть своя, то есть некоего справочника нет.

Например
1. от 0 до 100 попугаев – 100 рублей
2. от 101 до 120 попугаев – 105 рублей
3. от 121 до 100000 попугаев – 106 рублей
4. от 100001 до бесконечности попугаев – 1000 рублей

Вопрос – как лучше это реализовать, с учетом того, что предполагается, что шкалу будет задавать пользователь, а возможности платформы в плане интерфейса ограничены редактированием таблиц и примитивными формами, куда грид вставить нельзя.

Мне видится такое решение – для каждого договора с клиентом (в т.ч. и для уже действующего договора) пользователь может зайти в массив (таблицу) «Шкала стоимости» в котором он может добавлять, удалять и редактировать записи с графами «От», «До» и «Стоимость». В «От» и «До», соответственно, указывать диапазон «попугаев», в «Стоимости» - значение.

При этом в варианте «А» никакой логики на добавление, редактирование и удаление записей нет. Можно заводить пересекающиеся диапазоны, диапазоны с дырками и т.п. Но для того, чтобы эта шкала заработала (а, значит, у шкалы есть статус) – нужно выполнить отдельную операцию, которая будет проверять корректность заполнения массива – чтобы не было дырок в диапазоне, чтобы записи не пересекались по диапазонам и т.п. В случае ошибок шкала не заработает, а без работающей шкалы не работает договор.

В варианте «Б» логика уже при добавлении, редактировании и удалении записей. Мне кажется, что этот вариант с одной стороны понятнее для пользователя, интуитивнее, а с другой сложнее в реализации – слишком много нужно проверять и я пока даже не представляю как. Например нужно разбить один диапазон в середине на два – в варианте А я исправлю запись (например уменьшу третью запись исправляю как «от 121 до 500 – 106 рублей» ) и добавлю еще одну («от 501 до 100000 – 107 рублей»), чтобы закрыть дырку, а в варианте Б мне проверки при сохранении записи так не дадут сделать и придется удалять все диапазоны и заводить по нарастающей. Плюс варианте в том, что не нужно отдельной операции на корректность шкалы и не нужен статус шкалы, который пользователю малопонятен.

Вопрос был про то, где логику прикрутить - сразу при задании шкалы или потом, отдельно?

АнатоЛой, ok, я не понял прелести решения _мод )

Сначала не понял, теперь уже понял. Только вот пользователям надо будет привыкнуть, ведь отображать то-то как у меня можно, а вводить? Нужно будет только два значение указывать - конец диапазона и значение. А начало, получается, само вычислится, что для пользователя может быть неочевидно. Думаю надо еще подумать как сделать понятнее.

_мод, спасибо!