Persistance de l'argent dans la base de données. Décision de conception

Question

J'ai besoin d'une table pour stocker l'état d'une transaction financière. L’état de cette transaction peut être grossièrement modélisé par cette classe.

class FinancialTransaction
{
    Integer txId,
    Money oldLimit,
    Money newLimit,
    Money oldBalance,
    Money newBalance,
    Date txDate
}
class Money
{   
    Currency curr,
    BigDecimal amount
}

Ma conception initiale du schéma ressemble à ceci:

CREATE TABLE tx
(
    txId bigint(20) unsigned NOT NULL,
    oldlimit_currency varchar(3) NULL,
    oldlimit_amount decimal(7,5) default 0.00,
    newlimit_currency varchar(3) NULL,
    newlimit_amount decimal(7,5) default 0.00,
    ----snipped----
    PRIMARY KEY (txId)
)

Deux choses m'inquiètent:

1. Chaque transaction est effectuée sur la base d'une devise. Je n'ai pas suffisamment réfléchi à la possibilité de prendre en charge des transactions pouvant avoir lieu dans plusieurs devises. En supposant que cela ne change pas; alors ne serait-il pas plus économe en espace de ne gérer qu'une colonne de devise? Vais-je regretter cette solution simpliste?
2. Étant donné que chaque élément Money est un objet de valeur, devrais-je plutôt enregistrer tous les objets Money dans une table Money distincte et faire en sorte que la table d'origine utilise MoneyIds en tant que clés étrangères de la table Money?

C’est-à-dire

CREATE TABLE tx
(
    txId bigint(20) unsigned NOT NULL,
    oldlimit_money_id int NOT NULL,
    newlimit_money_id int NOT NULL,
    ----snipped----
    PRIMARY KEY (txId),
    FOREIGN KEY (oldlimit_money_id) REFERENCES MONEY(id) ON DELETE NO ACTION ON UPDATE NO ACTION,
    FOREIGN KEY (newlimit_money_id) REFERENCES MONEY(id) ON DELETE NO ACTION ON UPDATE NO ACTION
)

Existe-t-il d'autres conceptions?

Merci lazyweb.

Answer 1

La monnaie et la valeur monétaire étant deux concepts différents, il serait préférable de les séparer. Il n'est pas nécessaire de créer un tableau séparé pour les «valeurs», mais il serait préférable d'en avoir un pour les monnaies, car il s'agit d'entités distinctes. Le nouveau design ressemblerait à ceci:

CREATE TABLE tx
(
    id bigint(20) unsigned primary key,
    old_limit_currency_id int not null references CURRENCY(id),
    old_limit_value decimal(7,5) not null,
    new_limit_currency_id int not null references CURRENCY(id),
    new_limit_value decimal(7,5) not null
)

Vérifiez également que le nombre décimal (7,5) est suffisant pour vos scénarios, il est un peu faible. Un vieil adage dit: "Mieux vaut prévenir que guérir". :)

Answer 2

1. Si, à l'avenir, vous deviez prendre en charge les transactions entre deux devises, vous devriez pouvoir la modéliser comme deux transactions avec une de chaque devise.
2. Il semble que vos objets Money soient, sémantiquement, des valeurs plutôt que des entités. Je ne vois donc pas la nécessité de les séparer en tant qu’entités.

Answer 3

Qu'en est-il d'une troisième idée:

CREATE TABLE tx
(
  txId bigint(20) unsigned NOT NULL,
  currency varchar(3) NOT NULL,
  oldlimit decimal(7,5) default 0.00,
  newlimit decimal(7,5) default 0.00,
  ----snipped----
  PRIMARY KEY (txId)
)

Toutes les valeurs monétaires d'une transaction doivent être dans la même devise, n'est-ce pas?

Answer 4

S'il ne s'agit pas d'un excédent excessif, allez encore plus loin et stockez tous les montants / valeurs dans une seule devise et gérez un tableau des taux de change.