Дизайн бази даних: Розрахунок залишку на рахунку

Як створити базу даних для розрахунку залишку на рахунку?

1) Наразі я обчислюю залишок на рахунку з таблиці транзакцій. У моїй таблиці транзакцій є "опис", "сума" тощо.

Потім я б склав усі значення "суми", і це дозволило б визначити залишок на рахунку користувача.

Я показав це своєму другові, і він сказав, що це не є гарним рішенням, коли моя база даних росте, вона буде гальмуватися ???? Він сказав, що я повинен створити окрему таблицю для зберігання розрахованого залишку на рахунку. Якщо це було зроблено, мені доведеться вести дві таблиці, і, якщо це ризиковано, таблиця балансу рахунку може вийти з ладу.

Будь-яка пропозиція?

РЕДАКТУВАТИ : ВАРІАНТ 2: чи слід додати додатковий стовпець до моїх таблиць транзакцій "Баланс". тепер мені не потрібно переглядати багато рядків даних, щоб виконати мій розрахунок.

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

Сума $ 100, залишок $ 100.

Сума - 60 доларів, залишок - 40 доларів.

Сума $ 200, залишок $ 240.

Вікова проблема, яка ніколи не вирішувалася елегантно.

Усі банківські пакети, з якими я працював, зберігають залишок у сутності рахунку. Обчислити його на льоту з історії руху немислимо.

Правильний шлях:

• У таблиці переміщення є транзакція "відкриття залишку" для кожного рахунку. Це вам знадобиться через кілька років, коли вам потрібно буде перемістити старі рухи з таблиці активних рухів до таблиці історії.
• Суб’єкт рахунку має поле балансу
• У таблиці руху є тригер, який оновлює залишки на рахунках для зарахованих та дебетованих рахунків. Очевидно, що він має контроль над зобов'язаннями. Якщо у вас не може бути тригера, тоді повинен бути унікальний модуль, який записує рухи під контролем зобов’язань
• У вас є програма "мережа безпеки", яку ви можете запускати в автономному режимі, яка повторно обчислює всі залишки та відображає (і, за бажанням, коригує) помилкові залишки. Це дуже корисно для тестування.

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

Зверніть увагу, що ці методи застосовуються як до готівки, так і до цінних паперів.

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

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

Усі оновлення цієї пари таблиць повинні бути в транзакції та забезпечувати, щоб або все залишалося синхронізованим (і рахунок ніколи не перевищував ліміт), або транзакція відкочувалася назад. Як додатковий захід, ви можете запускати аудиторські запити, які періодично перевіряють це.

Це дизайн бази даних, який я отримав лише з однією таблицею для простого зберігання історії операцій / транзакцій. В даний час працює як шарм над багатьма невеликими проектами.

Це не замінює конкретний дизайн. Це загальне рішення, яке може відповідати більшості програм.

id : int стандартний ідентифікатор рядка

тип_ операції : тип операції int. платити, стягувати, відсотки тощо

тип_джерела : int, звідки триває операція. цільова таблиця або категорія: користувач, банк, постачальник тощо

source_id : int id джерела в базі даних

тип_цілі : int до того, до якої операції застосовується. цільова таблиця або категорія: користувач, банк, постачальник тощо

цільовий_ід : int id цілі в базі даних

сума : десяткова (19,2 підписана) цінова ціна додатна або від’ємна до підсумовується

баланс : десятковий (19,2 підписаних) результуючий баланс

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

created_at : часу

Для source_type і target_type було б краще використовувати enum або таблиці appart.

Якщо ви хочете отримати певний баланс, ви можете просто здійснити запит останньої операції, відсортованої за спадною межею create_at до 1.

Для кращої роботи рекомендується зберігати поточний баланс у необхідному цільовому об'єкті.

Загальним рішенням цієї проблеми є підтримка (скажімо) щомісячного залишку на відкритті в схемі знімків. Розрахунок поточного залишку можна здійснити, додавши дані про трансакції за місяць до щомісячного залишку. Цей підхід часто застосовується в пакетах рахунків, особливо там, де у вас можуть бути конвертація валюти та переоцінка.

Якщо у вас є проблеми з обсягом даних, ви можете архівувати застарілі залишки.

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

Звичайно, вам потрібно зберігати поточний баланс у кожному рядку, інакше це занадто повільно. Щоб спростити розробку, ви можете використовувати обмеження, так що вам не потрібні тригери та періодичні перевірки цілісності даних. Я описав це тут Денормалізація для забезпечення ділових правил: Запуск підсумків

Ваш друг помиляється, а ви маєте рацію, і я б порадив вам не змінювати речі зараз.
Якщо ваш db коли-небудь буде повільним через це, і після того, як ви перевірили всі інші (належне індексування), деяка денормалізація може бути корисною.
Потім ви можете помістити поле BalanceAtStartOfYear у таблицю Рахунки та підсумувати лише записи цього року (або будь-який подібний підхід).
Але я б точно не рекомендував такий підхід заздалегідь.

Ось я хотів би запропонувати вам, як ви можете зберегти свій початковий баланс дуже простим способом: -

1. Створіть функцію запуску в таблиці транзакцій, яка буде викликана лише після оновлення або вставки.

2. Створіть стовпець із назвою у головній таблиці іменування рахунків Відкриття балансу.

3. збережіть свій початковий баланс у масиві у стовпці початкового балансу в головній таблиці.

4. вам навіть не потрібно використовувати мову на стороні сервера, використовуйте цей масив магазину, просто ви можете використовувати функції масиву бази даних, такі як доступні в PostgreSQL.

5. коли ви хочете перерахувати залишковий баланс у масиві, просто згрупуйте таблицю транзакцій за допомогою функції масиву та оновіть цілі дані в головній таблиці.

Я зробив це в PostgreSQL і працюю чудово.

з часом, коли ваша таблиця транзакцій стане важкою, тоді ви можете розділити таблицю транзакцій на основі дати, щоб пришвидшити роботу. цей підхід дуже простий і не потрібно використовувати будь-яку додаткову таблицю, яка може сповільнити продуктивність при об’єднанні таблиці, оскільки менша таблиця в об’єднанні дасть вам високу продуктивність.

Мій підхід полягає в тому, щоб зберігати дебети в стовпці дебету, кредит у стовпці кредиту і при отриманні даних створювати два масиви, дебет і кредитний масив. Потім продовжуйте додавати вибрані дані до масиву і робіть це для python:

def real_insert(arr, index, value):
    try:
        arr[index] = value
    except IndexError:
        arr.insert(index, value)


def add_array(args=[], index=0):
    total = 0
    if index:
        for a in args[: index]:
            total += a
    else:
        for a in args:
            total += a
    return total

тоді

for n in range(0, len(array), 1):
    self.store.clear()
    self.store.append([str(array[n][4])])
    real_insert(self.row_id, n, array[n][0])
    real_insert(self.debit_array, n, array[n][7])
    real_insert(self.credit_array, n, array[n][8])
    if self.category in ["Assets", "Expenses"]:
        balance = add_array(self.debit_array) - add_array(self.credit_array)
    else:
        balance = add_array(self.credit_array) - add_array(self.debit_array)

Проста відповідь: виконайте всі три.

Зберігати поточний баланс; і в кожній транзакції зберігайте рух і знімок поточного залишку на той момент часу. Це дало б щось додаткове для узгодження в будь-якому аудиті.

Я ніколи не працював над основними банківськими системами, але я працював над системами управління інвестиціями, і на моєму досвіді це так робиться.