Цитата:
Сообщение от
Murlin
приходиться достаточно часто получать цены с учетом акций... но данные такие, что получать приходиться достаточно сложно каждый раз ломая себе голову... Затем я в дисплей методах получаю данные высчитывая согласно методу расчета в строке акции... Стоит ли такие данные немного денормализовать чтобы больше не мучиться?
Стоит пользователям сказать, чтобы не страдали ерундой и пользовались иногда отчетами
Зачем им это все в display-методах-то? Если надо посчитать, как такой-то прайс будет выглядеть с учетом акций, можно сделать отчетик или отдельную форму, которая будет обсчитываться на сервере в момент вызова. Надо посмотреть - нажми на кнопочку вызова формы.
А вообще, когда часто используемые расчетные данные так сложно искать, то обычно дело всё - в смешении данных, удобных для работы пользователей, и данных, удобных для работы системы. Шапки, строки, пять таблиц, необязательность заполнения полей, изменения задним числом... брр! Это все для пользователей, это все в журналах каких-нить должно быть. А для системы должна быть одна плоская транзакционная таблица, где все данные проверены, все неоднозначности разрешены и все нужные поля заполнены. И должен быть механизм трансляции из шапок со строками в плоскую таблицу. Это все давно уже придумано - поглядеть хоть на любой модуль Аксапты. Есть журналы, есть транзакционная таблица с движениями по учетным единицам, и есть механизмы разноски этих журналов, которые берут на входе шапки-строки, проверяют, дополняют недостающими данными из справочников/настроек/etc и генерят записи в плоских транзакционных таблицах, которые потом очень удобно фильтровать/агрегировать и куда пользователи своими грязными руками лазить не могут. На разноске - куча проверок, сложные вычисления, решение систем линейных уравнений, что угодно; при работе с транзакционной таблицей - только простые запросы без каких-либо неоднозначностей, максимум maxof/minof, фильтры по дате/клиенту/номенклатуре.