
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
08.04.2009, 15:02
|
|||
|---|---|---|---|
Как соблюсти обязательность заполнения опциональных структур |
|||
|
#18+
Есть такое понятие как "Тарифный план" в нем есть куча фиксированных коэффициентов, а также некоторое количество динамических сложных коэффициентов, зависимых от 2х и более параметров (к примеру, цена+предоплата -> коэф скидки) и таких коэффициентов в каждом тарифном плане может быть от 0 до N (или лучше - до M :) ) Описать тарифный план - не проблема Проблема в том как в описать структуру договора, в котором в соответствии с указанным в договоре тарифном плане должны быть обязательно заполнены все эти коэффициенты?? TariffPlans ----------------- TariffPlanID Title CompositKoeffs ---------------- CompositKoeffID Title KoeffParams1 ---------------- KoeffParam1ID Title KoeffParams2 ---------------- KoeffParam2ID Title TariffPlan_CompositKoeffs --------------------------- TariffPlanID CompositKoeffID KoeffParam1ID KoeffParam2ID Koeff Contracts ---------------- ContractID TariffPlanID а дальше непонятно как поступать? заранее не известно количество таких параметров в тарифном плане Кто сталкивался с такой постановкой задачи - поделитесь опытом пожалуйста ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.04.2009, 16:23
|
|||
|---|---|---|---|
|
|||
Как соблюсти обязательность заполнения опциональных структур |
|||
|
#18+
spа дальше непонятно как поступать? Если сущность требует наличия определенных условий, чтобы ей можно было пользоваться, можно ввести понятие "утверждения" сущности (смена статуса сущности). При утверждении в хранимой процедуре остается проверить все, что хочется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.04.2009, 18:49
|
|||
|---|---|---|---|
Как соблюсти обязательность заполнения опциональных структур |
|||
|
#18+
Сергей Васкецовspа дальше непонятно как поступать? Если сущность требует наличия определенных условий, чтобы ей можно было пользоваться, можно ввести понятие "утверждения" сущности (смена статуса сущности). При утверждении в хранимой процедуре остается проверить все, что хочется. С помощью кода проверить - не проблема, хотелось бы на уровне структуры решить вопрос ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.04.2009, 09:30
|
|||
|---|---|---|---|
|
|||
Как соблюсти обязательность заполнения опциональных структур |
|||
|
#18+
spС помощью кода проверить - не проблема, хотелось бы на уровне структуры решить вопрос Разработка структуры общего вида для произвольной проверки произвольных данных на корректность без "помощи кода" займет у Вас бесконечное время и будет стоить бесконечных денег. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.04.2009, 13:46
|
|||
|---|---|---|---|
Как соблюсти обязательность заполнения опциональных структур |
|||
|
#18+
Сергей ВаскецовspС помощью кода проверить - не проблема, хотелось бы на уровне структуры решить вопрос Разработка структуры общего вида для произвольной проверки произвольных данных на корректность без "помощи кода" займет у Вас бесконечное время и будет стоить бесконечных денег. Спасибо за надежду - умеете поддержать в трудную минуту ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.04.2009, 10:53
|
|||
|---|---|---|---|
Как соблюсти обязательность заполнения опциональных структур |
|||
|
#18+
Можно зайти со стороны бизнес-реинжиниринга. Традиционно многие бизнесы выдумывают всякую мудистику с десятками тарифов и прочей динамистикой, а иногда помогает предельно упростить продуктовую линейку - в результате снижаются косты (ваша работа над этим вопросом - тоже ложится на косты), покупателям проще сделать выбор - консультант может больше обслужить, снижается время обработки транзакции, число ошибок и т.д. Теряя на мудистике копейки, бизнес на скорости и спрямлении выигрывает рубли. В некоторых случаях выгодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.04.2009, 00:09
|
|||
|---|---|---|---|
Как соблюсти обязательность заполнения опциональных структур |
|||
|
#18+
А6дуллаhМожно зайти со стороны бизнес-реинжиниринга. Традиционно многие бизнесы выдумывают всякую мудистику с десятками тарифов и прочей динамистикой, а иногда помогает предельно упростить продуктовую линейку - в результате снижаются косты (ваша работа над этим вопросом - тоже ложится на косты), покупателям проще сделать выбор - консультант может больше обслужить, снижается время обработки транзакции, число ошибок и т.д. Теряя на мудистике копейки, бизнес на скорости и спрямлении выигрывает рубли. В некоторых случаях выгодно. С благодарностью бы выслушал ваши предложения по убиранию этой мудистике - предложите как если это просто разглагольствования - то глупо любую попавшуюся под пальцы мысль тут печатать, а если же это реальное предложение - то я и многие многие тут вам спасибо скажут Скажите как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=32&mobile=1&tid=1543306]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
167ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 292ms |
| total: | 553ms |

| 0 / 0 |
