Добрый день!
Недавно с другом, программистом на С++, возникла дискуссия на тему какие данные правильно хранить в базе, а какие рассчитывать. Прошу помощи у общественного сознания, для разрешения этого вопроса.
К примеру у нас есть документ с табличной частью, в этой табличной части есть три группы данных:

А. Первичные данные:
-Номенклатура;
-Количество;
-Цена;
-Процент скидки;
-Цена себестоимости;

Б. Прямые расчетные данные:
-Сумма;
-Сумма скидки;
-Сумма себестоимости;

В. Не прямые расчетные данные.
-Процент от общей суммы в документе;
-Процент от максимальной суммы в документе;

Вопрос, какие из этих блоков необходимо хранить в базе, а какие рассчитывать.
С блоком А понятно, его хранить необходимо в любом случае.
Вопросы по блокам Б и В.
Если будет обоснование выбранного варианта буду благодарен:)

(0)[Недавно с другом, программистом на С++, возникла дискуссия на тему какие данные правильно хранить в базе, а какие рассчитывать. ]

форум не комментирует религиозные споры кодеров разных конфессий

глупый детский спор в песочнице

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

"какие из этих блоков необходимо хранить в базе, а какие рассчитывать" // Кому необходимо?

(0) Зависит от ТЗ. Какие впоследствии данные понадобятся. Для отчетов, для изменения условий скидок.

(0) Блок Б.
Результат операции. Будет использоваться в дальнейших расчетах (отчетах). Каждый раз рассчитывать построчно сумму взаиморасчетов - есть полный бред. Хранить в базе.
Блок В.
Потешить любопытство. Ни на какие дальнейшие расчеты не влияет. Можно не хранить.
А вообще см.(2)

(5) > Ни на какие дальнейшие расчеты не влияет.

Зависит от бизнес-процессво предприятия.

(6) Ага.

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

Из блока "Б" - храним только Сумма и Сумма скидки. Они ведь не могут поменяться после того, как покупатель уже ушёл. Сумма себестоимости может храниться в документе в том случае, если она рассчитывается только единожды при записи документа и никогда в последующем не будет меняться вне зависимости от исправлений предшествующих данных.

Из блока "В" данные можно хранить в документе. Но см (2) - надо понимать, что это занимает место в базе. И хранить их в базе имеет смысл только, если эти данные очень часто нужны, а их расчет - очень трудозатратен для системы.

ОФФ. Согласен с оратором (2) - вопрос тупой и странный.

И вообще. Что значит "в документе"? Записи регистров, привязанные к регистратору (документу) - это данные "в документе" или "вне документа"?

(2) Помимо быстродействия есть же ещё вопрос удобства.
Условно если данные в базе не хранить, то формулы по их расчету будут в нескольких местах, в запросе для отчетов, на форме для отображения, в каком нибудь источнике данных и печатной форме, и при каждом изменение формулы нужно будет править их во всех местах. Но при добавление данных не через форму(стороннее соединение, загрузка из экселя и т.д.) не нужно будет задумываться о их правильном расчете, достаточно занести первичные данные.

(9) если при открытие формы документа необходимо проделать какие то операции, а не просто вывести реквизит на форму - это вне документа.

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

(10) ага, а теперь покажи мне, где в (2) я пишу, о том, что руководствоваться надо быстродействием?

Хранить надо любой чих, если планируешь задерживаться в фирме или иметь положительную карму от программистов - потомков.

Зависит от тз, например есть показатель который считается из 100500 параметров, и если массив данных типа 10 млн ед. считает этот показатель будет просто убийственно долго. Другое дело если от рассчитан и лежит в регистре.
Если массив данных 1000 то пусть считается демонически ..

(14) главное - не дублировать реквизиты. А то бывают базы 1С где реквизиты Сумма и НоваяСумма. и хз, что использовать

(10) Какой феерический бред.
Ни быстродействие, ни удобство не имеют значения.
Значение имеет лишь конкретный бизнес-процесс и то как он реализован в конкретном прикладном решении (вне зависимости от того на каком языке программирование оно написано).

Например, какой смысл хранить себестоимость в самом документе, если в соответствии с бизнес-процессом она может меняться (документы заводят не в хронологическом порядке и перепроводят задним числом, например)?

Или с какого перепугу надо каждый раз пересчитывать сумму скидки, если эта скидка предоставлена была в момент продажи, будучи рассчитанной по правилам, действовавшим на тот момент. И как рассчитать скидку в документе годовалой давности, если правила 5 раз с тех пор поменялись? - Хранить в документе или где-то еще сами правила расчета скидки?

У автора каша в голове. И не видно никакого прояснения.
ИМХО.

(0) А - хранить, Б - хранить.
В - непонятная хрень. Проанализировать для чего нужна и какие нужны ресурсы для получения актуальных данных. Если "быстрее" хранить, чем "получать" - тоже хранить.

(0) + (15) Попробуйте сформировать отчет по ССЧ в зуп за год в по компании в которой десятки тысяч сотрудников.. сразу все поймете ..

(10) открой для себя разницу OLTP и OLAP
(17) +100500

(12) Не понял вашу мысль, уточните, пожалуйста.

Кстати,в sql таблицах есть понятие рассчитываемое поле для таких целей,чтобы было ощущение,что хранится,но не было хранения.

(21) "Но"

это рассчитывается:

Б. Прямые расчетные данные:
-Сумма себестоимости;

В. Не прямые расчетные данные.
-Процент от общей суммы в документе;
-Процент от максимальной суммы в документе;

(13) На прямую на это отсылки не было, но фраза " Чем больше хранишь, тем больше весит. Чем больше рассчитываешь, тем медленнее работает." относиться больше к производительности, нежели к принципу по которой данные заносяться в БД.
(14)  Спасибо за первое конкретное мнение.
(17) Если абстрагироваться от негатива в вашем сообщение, то давайте рассмотрим  ваши примеры.
По бизнес процессу мы хотим видеть себестоимость на момент создания документа. Себестоимость нельзя заносить задним числом. Себестоимость храниться в отдельном периодическом регистре сведений.
какой вариант выберете вы:
1 . При открытие формы получать данные из регистра сведений, и выводить их на форму.(для отчетов вам тоже прийдется получать эти данные из регстра отдельно)
2. Заносить данные в документ.
Пример 2.
В документе есть стоимость в рублях и сумма скидки в рублях. Расчитывается процент этой скидки.
Процент нужно хранить в базе?
Для варианта хранения:
+ во всех отчетах и печатных формах вы просто берете значение из базы и выводите.
- Если формула изменилась, и вам нужно в старых документах видеть данные по актуальной формуле, необходимо либо обрабатывать все документы, либо опять же править все отчеты добавляя новые условия.
Для варианта расчета:
- если в какой то момент формулу расчета скидки решат поменять(Для примера, не учитывать НДС в стоимости) , вам необходимо править все печатные формы, отчеты и т.д.
+при занесение данных сторонними методами(внешнее подключение, групповые обработки и т.д.) вам не нужно переживать о расчете доп данных. Вы заносите только первичные данные.
(18) приведенные реквизиты исключительно для примера расчетов, по которым недостаточно данных текущей строки, но нужно учитывать и другие строки в документе. Просто хочу для себя понять сам принцип, по которому "правильнее"(удобнее, практичнее и т.д.)  хранить данные в базе.

(0) Все давно разобрано по полкам до нас. Нам остается только изучить и использовать.

Нормализация отношений. Шесть нормальных форм: https://habr.com/ru/post/254773/

(25) Мои подозрение о каше в голове только усиливаются.
Не обижайтесь. Просто либо сказывается недостаток образования, либо опыта.
Вы даже не можете сформулировать задачу связно.
А ведь именно исходя из конкретных условий задачи будет приниматься решение о том, где хранить данные.

Что касается примеров.


>> Пример 1. мы хотим видеть себестоимость на момент создания документа. Себестоимость нельзя заносить задним числом.

Что значит "заносить задним числом"? Вы сами понимаете что пишите? Осмелюсь предположить, что речь идёт о том, что себестоимость, рассчитанная при записи документа, не может меняться в последующем. Если я прав, то в таком случае действительно можно хранить себестоимость в документе. Собственно говоря именно такой пример я привёл в (8).

Другой вопрос, что ни одна из типовых конфигураций 1С (УТ, БП, КА, УПП, ERP) не предусматривают подобную логику событий. И я с ними склонен согласиться. Ибо я ещё не видел ни одной организации, где документы вносили в базу данных в строгом хронологическом порядке, позволяющем рассчитать себестоимость корректно и один единственный раз. Но это всё лирика. Требования определяет бизнес. Если бизнес сказал, что считаем себестоимость при записи и никогда в жизни её не меняем, то пусть так - можно хранить и в документе.

Про периодический регистр сведений относительно себестоимости вообще ничего не понял. Какой-то горячечный бред.

>> Пример 2.
>> В документе есть стоимость в рублях и сумма скидки в рублях. Расчитывается процент этой скидки.

Очередная безумная постановка задачи.
Если есть сумма 100 рублей и сумма скидки 15 рублей, то как может поменяться величина предоставленной скидки - 15% ? Да хоть каждый день по 100 раз меняй формулу, скидка предоставленная покупателю вчера  в 15 рублей уже не поменяется. Хранить ли этот самый процент (15%) в базе или рассчитывать каждый раз - не имеет принципиального значения (кроме некоторой избыточности). Т.к. сам расчет простой и никак не зависит от каких-то там формул, которые у тебя где-то там в каких-то печатных формах меняются. Даже через 100 млн лет 15 рублей от 100 рублей - это будет 15%, а не 20% и не 10%. Хоть ты тресни. Это арифметика за 4 класс.