Дизайн базы данных: таблица транзакций учета
Сохранение записи транзакции в базе данных учета двойного ввода.
Я придумал вариант 1 варианта 1 и вариант 2, мне сказали, что большинство банковских пакетов выбирает вариант 2 для своего дизайна базы данных. Однако я предпочитаю вариант 1 над вариантом 2, потому что он просто имеет смысл, и он более эффективен!
I.e Для 2-х перемещений средств вариант 1 требует, чтобы 2 записи по сравнению с вариантом 2 требовали 4 записи.
Я хотел бы знать, почему банк выбрал вариант 2 по варианту 1? Что является причиной этого?
Option 1)
TRANSACTION
Credit_AccountId
Debit_AccountId
Amount
...
Option 2)
TRANSACTION
AccountId
Amount
...
Ответы
Ответ 1
Вариант 1 потенциально может быть более эффективным с точки зрения вставки. Но поскольку многие учетные транзакции будут влиять на более двух учетных записей, преимущество, вероятно, будет значительно меньше 2: 1.
Вариант 2 будет более понятным для этих более сложных транзакций. То есть, бухгалтер обычно найдет три строки
- Дебет A $100
- Кредит B $60
- Кредит C $40
более ясно, чем две строки
- Дебет A $60 Кредит B $60
- Дебет A $40 Кредит C $40
Если у вас несколько учетных записей с обеих сторон, было бы также неясным, как сопоставить дебет и кредиты с одной учетной записью. То есть
- Дебет A $100
- Дебет B $30
- Кредит C $60
- Кредит D $70
может быть представлен как
- Дебет A $60 Кредит C $60
- Дебет A $40 Кредит D $40
- Дебет B $30 Кредит D $30
но есть и другие возможные способы построения данных для модели данных 2.
Кроме того, вариант 2 будет более эффективным, если вы попытаетесь определить текущий баланс определенной учетной записи путем агрегирования транзакций.
Ответ 2
В общем дизайне базы данных бухгалтерского учета логично и эффективно хранить ваши списания и кредиты в одном поле (например, вариант 2), поскольку это упростит агрегацию, числовые манипуляции и отчетность. Для каждого дебетового и кредитного транзакций должно быть поле даты и времени, чтобы отфильтровать определенный период. Получите книгу от Smashwords, озаглавленной, дизайн базы данных учета. Он предоставляет несколько хороших образцов для проектирования системы учета и некоторый интересный запрос sql для финансовой отчетности.