Блог

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

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

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

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

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

«Это зависит от обстоятельств». Чаще всего вы хотите избежать получения производных данных. Однако бывают случаи, когда наличие полученного итога оправдано.

Показательный пример:

Я работал над приложением кредитной базы данных, где баланс состоял из множества разных вещей и разных бизнес-правил с течением времени. Например, «баланс» на самом деле представлял собой сумму различных балансов из разных сегментов, таких как Основная сумма, Сборы и т.д.

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

Представьте, что вы на лету запрашиваете 100 000 балансов клиентов в условиях изменения бизнес-правил с течением времени. Это убедительный случай, когда наличие производного значения действительно имеет смысл. Мы использовали набор алгоритмов для «перемотки» учетной записи и восстановления баланса в хронологическом порядке для целей аудита и проверки, но это было не то, что вы хотели бы сделать для больших наборов.

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

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

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

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

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

Используйте представления и запросы — вы будете удивлены тем, как быстро он будет работать.