Persistierende Geld in die Datenbank. Design-Entscheidung

Question

Ich brauche eine Tabelle, die den Zustand einer Finanztransaktion zu speichern. Der Zustand dieser Transaktion kann grob von dieser Klasse modelliert werden.

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

Mein erster Entwurf des Schemas sieht wie folgt aus:

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)
)

Zwei Dinge beunruhigen mich:

1. tritt Jede Transaktion auf einer Währung basiert. Ich habe nicht weit genug gedacht, ob ich brauchen könnte Transaktionen zu unterstützen, die in mehreren Währungen passieren können. Unter der Annahme, dass es sich nicht ändert; dann ist es nur eine Währungsspalte nicht mehr Platz spar aufrecht zu erhalten? Werde ich diese vereinfachende Lösung bereuen?
2. Da jedes Geld Element ist ein Wertobjekt, soll ich stattdessen alles Geld spart ein separaten Geldtabellenobjekte in und habe die Original-Tabelle Verwendung moneyIds als Fremdschlüssel des Geld Tisch?

Das heißt,

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
)

Gibt es alternative Entwürfe?

Danke lazyweb.

Answer 1

Die Währung und Geldwert sind zwei verschiedene Konzepte so wäre besser, sie zu trennen. Es besteht keine Notwendigkeit für ‚Werte‘ eine separate Tabelle zu machen, aber besser wäre, einen für Währungen zu haben, weil diese sind getrennte Einheiten. Das neue Design würde wie folgt aussehen:

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
)

Überprüfen Sie auch, ob dezimal (7,5) genügend Platz für Ihre Szenarien hat, ist es ein wenig niedrig aussieht. Es gibt ein altes Sprichwort: „Sicher ist sicher“:)

Answer 2

1. Wenn Sie in Zukunft Transaktionen zwischen zwei Währungen unterstützen müssen, es sollte dies als zwei Transaktionen möglich sein, mit einem der jeweiligen Währung zu modellieren.
2. Es sieht aus wie Ihre Money-Objekte sind, semantisch, Werte eher als Entitäten. So sehe ich nicht die Notwendigkeit, sie als Entitäten zu trennen.

Answer 3

Was ist eine dritte Idee:

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)
)

Alle Geldwert einer Transaktion müssen von der gleichen Währung sein, nicht wahr?

Answer 4

Wenn es nicht zuviel des Guten ist, gehen noch einen Schritt weiter und speichern Sie alle Beträge / Werte in einer einzigen Währung und pflegen einen Wechselkurse Tabelle.