Я, лично, придерживаюсь мнения, что данные с которыми выполняется работа должны быть уже готовые к использованию - взял и вывел.

А 1C, похоже, считает наоборот:
1) Галка "Входит в холдинг" в контрагентах. Расчитывается при открытии формы. А в запросах приходится прописыввать условие
2) Сумма всего в документе "Реализация..." . Расчитывается при выводе строки.
3) и т.д

Часто используемые - хранить. Удобство и надежность разработки в системе заметно возрастает

А середину выбрать нельзя?

примеры точечные, не объективные. Есть много инфы, что хранится уже рассчитанная, исходя из целесообразности

Галка входит в холдинг плохой пример вообще, галка для юзера, на данные другие опирается

(0) топик ни о чем

Всё решает здравый смысл, не надо перегружать систему "лишней" рассчитаной инфой, но и рассчитывать всё не надо

(0) Ты думаешь ты умнее Нуралиева? =)

(6) ты думаешь Нуралиев в курсе, что там расчитывается, а что хранится? ))

(3) у нас например на нее очень много завязано - отгружаем торговым точкам, а деньги получаем с головного клиента.
Везде приходиться прописывать кодом условие на головного

(5) согласен. Но как показывает практика, что хоть раз надо было подсчитать, будет требоваться для анализа.

Вот сейчас думаю про просроченную задолжность. Ее надо будет выгружать на КПК т.е скорость получения данных должна быть высокой. Но она непостояная - все время меняется поэтому хранить в классическом виде нельзя. А алгоритм тяжелый.

Думаю делать гибрид - непериодический регистр, который заполняется рег. заданием.

идея РСУБД как раз в однозначности трактовки данных.
хранение расчетных данных обеспечивает более высокую надежность, чем алгоритм.

тужа же поддержка дублей алгоритмов задача сложная сама по себе.

Обычная проблемма нормализации/денормализации.
Если хранить расчетные - надо предусмотреть пересчет этих расчетных при изменении изначальных условий.
В зависимости от частоты(сложности) изменения первоначальных данных и принимается решение.
Кстати 1С вполне юзает денормирование. Те же остатки регистров.

Забыл проголосовать

(9) только при условии, что вы храните согласованные данные ))

Если говорить про ВходитВХолдинг то его наверное лучше хранить, если есть частое вычисление данного признака. Поскольку контроль за изменением данного реквизита совсем не сложный. И подобный признак меняется редко

(10) или партии товаров

У вот опять дилема.
У головного контрагента есть торговые точки и договора. Договор заключается с головным. Следовательно договора торговых точек должны наследоваться.
И 2 варианта решения - добавление реквизита (ДоговорГоловного) или связывать по определенной комбинации реквизитов