Когда сделать вычисления

Сохраните все данные для каждого элемента, так как они обычно вам понадобятся позже (для статистических / информационных целей или по любым другим причинам). Вы должны убедиться, что вы всегда следуете одной и той же логике расчета, чтобы получить общую продажную цену. Так что вам, возможно, придется хранить вместе с ними валюты, скидки, единицу цены и т. Д.Вот еще несколько моментов, которые следует учитывать:

• Если вы хотите вывести цену отдельной позиции позже, вам потребуются данные одной позиции.

• Не сохраняйте общую цену вместе с данными об отдельном элементе, так как вам придется всегда синхронизировать и то и другое. Спустя месяц или годы вы будете озадачены, какой из них использовать для своих расчетов.

• Объедините свои данные, если вы используете их в хранилище данных и не нуждаетесь в деталях.

Это проблема 3-й нормальной формы .

Вариант 1 находится в 3-й нормальной форме. Нет никаких производных данных. Расчет необходимо производить для каждого запроса. Благодаря этому обновления можно производить в любом поле, ничего не нарушая.

Вариант 2 нарушает 3-ю Нормальную форму. Сохраняет производные данные. Вычисления не выполняются во время запроса, что значительно ускоряет их. Однако обновление, которое также не повторяет расчет, приведет к несогласованным данным. Это называется «аномалией обновления». Обновление приводит к несогласованности поля производных данных.

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

Это зависит от того, что вы собираетесь делать с данными.

Для многих целей целесообразно хранить под каждым товаром цену за единицу товара, количество купленного товара и расширенную цену. Расширенная цена - это количество, умноженное на цену единицы товара. Избыточно ли это? Ну, да. Нарушает ли это некоторую нормальную форму? Ну, да. Но это работает достаточно хорошо.

Зачем хранить цену в строке (записи) товара, а не просто полагаться на те же данные о цене, которые хранятся в основной таблице товара? Потому что если вы измените цену после этой продажи, вы не захотите менять цену, которую понес данный клиент при этой покупке. Зачем хранить расширенную цену, ведь ее можно пересчитать на лету? Потому что это на один шаг упрощает последующее агрегирование (суммирование или усреднение) по некоторому набору товаров.

Если вы храните расширенную цену, вы можете использовать инструменты анализа "наведи и щелкни", "сверни вниз" (см. OLAP) для последующего анализа без дополнительного программирования. Если вы рассчитываете на повторное вычисление расширенной цены, когда она вам понадобится, вы можете обнаружить, что инструмент детализации недостаточно умен, чтобы сделать умножение за вас.

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

Обычно я стараюсь, чтобы мои данные были нормализованы. Это одно из мест, где многие эксперты намеренно отклоняются от требований чистой нормализации.

Я бы сказал, что всегда нужно хранить стоимость и цену как отдельные колонки И хранить общую сумму. Наступит время, когда вам понадобится их разделение (отчетность, выставление счетов), и вы пожалеете об этом.

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

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

Лично я всегда храню общую сумму. Я просто считаю, что стоимость дополнительного столбца базы данных всегда перевешивается наличием этой общей суммы в других местах.

Я бы сохранил стоимость товара и продажную цену за товар. Если вы сохраняете только итоги, вам будет сложно пересчитать ваши значения, если цены изменятся. Представьте, что вы предоставляете сезонную скидку на некоторые из ваших товаров, применяете разные налоги к некоторым товарам (возможно, даже разные в зависимости от страны происхождения покупателя) или предоставляете более низкие цены для зарегистрированных клиентов - вам придется рассчитывать эти цены на основе продаж цена товара, итоги в этом случае не нужны.

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

ИМХО магазинная себестоимость и продажи на единицу товара. Если вы хотите, чтобы результаты были как итоговые, либо выполните их внутри запроса, либо создайте временную таблицу или хранимую процедуру с вычислениями. Однако я обычно выполняю эти вычисления в коде (в моем случае PHP или JAVA). Если это используется только для целей отчета, иногда можно сохранить итоги, чтобы ускорить вычисления (и предотвратить некоторые ошибки в вычислениях в вашем коде).

Я бы сохранил итоги только в том случае, если у меня есть серьезная проблема с отчетами, когда для многих запросов требуется общее значение большого набора записей (если вы получаете только общая сумма для небольшого набора, расчет на лету по запросу - в порядке).

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