Хранение «производных» значений против их расчета при извлечении - PullRequest
7 голосов
/ 21 апреля 2010

Если у вас есть значения, которые зависят только от одного или нескольких других полей +/- констант (скажем, розничная цена и цена со скидкой), лучше также хранить эти значения или вычислять их «на лету» при извлечении данных

Ответы [ 2 ]

8 голосов
/ 21 апреля 2010

По умолчанию не хранится избыточная информация: третья нормальная форма обычно является разумной начальной целью. Избыточность вводится, когда появляется «достаточно хорошая» причина, например, «достаточно большая» хит производительности, который вы получаете, когда вам нужно вычислить производное значение и интенсивный расчет.

Очевидно, что «достаточно хороший» и «достаточно большой» - это квалификаторы, которые только что-то значат в данном контексте. Что бы это ни стоило, расчет розничной цены / цены со скидкой кажется слишком дешевым и простым, чтобы оправдать введение избыточного столбца в большинстве (очевидно, не во всех) случаях.

6 голосов
/ 21 апреля 2010

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

Существуют исключения, которые стоит учитывать, но не связанные с производительностью базы данных.

  • Когда вычислять значение больно (например, какая-то сложная математическая функция), тогда имеет смысл сохранить (вы можете представить столбец как «последнее вычисленное значение»).
  • У вас могут быть входные данные, которые со временем меняются, например, плата определяется по ставке платы, но ставка платы сохраняется в таблице конфигурации как отдельное значение. Возможно, вы захотите записать комиссию, потому что исторические комиссии будут рассчитываться только из текущей ставки комиссии. В качестве альтернативы, вы можете сохранить показатель по времени, чтобы обойти эту проблему.
  • Если производное значение может быть переопределено пользовательским вводом или каким-либо другим процессом, то снова имеет смысл сохранить. В качестве альтернативы вы можете смоделировать это с двумя состояниями 'CALCULATED' и 'OVERRIDDEN', так что вы сохраняете значение только в последнем состоянии.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...