Лучше ли кэшировать какое-либо значение в таблице базы данных или пересчитывать его каждый раз?

Question

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

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

Что бы вы порекомендовали?

Answer 1

хороший вопрос!

По моему мнению, вы всегда должны избегать дублирования данных, поэтому я бы использовал опцию "суммирования" каждый раз

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

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

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

Answer 2

В некоторой степени это зависит.

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

Также необходимо рассмотреть вопрос о порядке доступа к данным / их использования. В готовой тяжелой системе, где вы «пишете один раз, готовите много», подход SUM снижает производительность при каждом чтении - в этом сценарии может иметь смысл один раз снизить производительность при записи, чтобы улучшить производительность последующего чтения.

Если вы ожидаете «большие» объемы данных, я бы определенно использовал дополнительную таблицу для хранения итогов высокого уровня. Однако необходимо убедиться, что он обновляется при выполнении (денежной) транзакции внутри транзакции (sql server), чтобы сделать ее атомарной операцией.

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

Answer 3

Это пример Денормализация .

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

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

Answer 4

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

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