Разработка базы данных: расчет баланса счета

Как мне создать базу данных для расчета баланса аккаунта?

1) В настоящее время я рассчитываю остаток на счете из таблицы транзакций В моей таблице транзакций есть "описание" и "сумма" и т.д.

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

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

Любое предложение?

EDIT: ВАРИАНТ 2: следует ли добавить дополнительный столбец в мои транзакционные таблицы "Баланс". теперь мне не нужно проходить много строк данных для выполнения моих вычислений.

Пример Джон покупает кредит в размере 100 долларов, он долги 60 долларов, а затем добавляет кредит в размере 200 долларов.

Сумма $100, Баланс $100.

Сумма - $60, Баланс $40.

Сумма $200, Баланс $240.

Ответ 1

Старая проблема, которая никогда не была изящно решена.

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

Правильный путь:

Таблица движения имеет "открытие" баланса "для каждого счета. Вам понадобиться это через несколько лет, когда вы необходимо переместить старые движения из активный стол движения к истории таблица.
У объекта счета есть баланс поле
Существует триггер движения таблица, которая обновляет учетную запись балансы для зачисленных и дебетовых счетов. Очевидно, что у него есть обязательства контроль. Если у вас нет триггера, тогда должен быть модуль уникальный, который записывает движения под контролем приверженности
У вас есть программа "безопасности", которую вы может работать автономно, что перерасчет все балансы и дисплеи (и необязательно исправляет) ошибочные противовесы. Это очень полезно для тестирование.

Некоторые системы хранят все движения как положительные числа и выражают кредит/дебет путем инвертирования полей from/to или флагом. Лично я предпочитаю кредитное поле, дебетовое поле и подписанную сумму, что значительно упрощает переход.

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

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

Ответ 2

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

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

Ответ 3

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

Если у вас есть проблемы с объемом данных, вы можете архивировать старые балансы.

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

Ответ 4

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

Ответ 5

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

Ответ 6

Здесь вы хотели бы предложить вам, как вы можете сохранить свой начальный баланс очень простым способом: -

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

Я сделал это в PostgreSQL и отлично работал.

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

Ответ 7

Это проект базы данных, в котором я получил только одну таблицу для простого хранения истории операций/транзакций. В настоящее время он работает как прелесть многих небольших проектов.

Это не заменяет определенный дизайн. Это общее решение, которое может соответствовать большинству приложений.

идентификатор: ИНТ стандартный идентификатор строки

operation_type: ИНТ работа type. платить, собирать, проценты и т.д.

source_type: ИНТ откуда происходит операция. целевая таблица или категория: пользователь, банк, поставщик и т.д.

source_id: ИНТ id источника в базе данных

target_type: ИНТ к какой операции применяется. целевая таблица или категория: пользователь, банк, поставщик и т.д.

target_id: ИНТ id цели в базе данных

количество: десятичная (19,2 подписка) значение цены положительное или отрицательное до суммированного

account_balance: десятичный (19,2 подписан) результирующий баланс

extra_value_a: десятичный (19,2 подписан) [это был самый универсальный вариант без использования хранилища строк] вы можете сохранить дополнительный номер: процентный процент, скидку, сокращение и т.д.

created_at: метка времени

Для source_type и target_type было бы лучше использовать app перечисления enum или таблиц.

Если вы хотите получить конкретный баланс, вы можете просто запросить последнюю операцию, отсортированную по убыванию, спустив ограничение на 1. вы можете запросить источник, target, operation_type и т.д.

Для повышения производительности рекомендуется сохранить текущий баланс в требуемом целевом объекте.

Ответ 8

Простой ответ: Сделайте все три.

Сохранить текущий баланс; и в каждой транзакции хранят движение и моментальный снимок текущего баланса в этот момент времени. Это дало бы что-то extra для согласования в любом аудите.

Я никогда не работал над основными банковскими системами, но я работал над системами управления инвестициями, и по моему опыту это было сделано.