我有一个维护特定业务交易的表,我们称之为
记录的状态只能由应用程序用户执行的“事件”或操作更改(某些事件不会导致状态更改,例如付款修改记录但不更改状态)。在跟踪当前状态的同时,重要的是我们能够轻松地跟踪将交易置于此状态的“事件”。
我看到其他数据库的设置方式是,
这个解决方案可行,但我担心这可能会导致数据完整性丢失。换句话说,没有任何东西防止状态被设置为“违约”,而没有支持更改的
我的备选解决方案是放弃
我的问题是:
1.我应该担心数据完整性吗(这是一个常见的事情,因此可以这样做)?
2.我的提议解决方案是否可靠,或者是否有更好的解决方案?
3.我的解决方案中是否存在任何陷阱,我应该注意?
LOANS
。每条记录在任何时候都可以具有多种“状态”,例如“正在还款/打开”,“违约”,“作废”或“已付款”。记录的状态只能由应用程序用户执行的“事件”或操作更改(某些事件不会导致状态更改,例如付款修改记录但不更改状态)。在跟踪当前状态的同时,重要的是我们能够轻松地跟踪将交易置于此状态的“事件”。
我看到其他数据库的设置方式是,
LOANS
包含一个状态列,并使用字母(甚至是指向可能状态表的外键)来指定当前状态。然后,EVENTS
表具有一个列,该列是对LOANS
的FK
。这个解决方案可行,但我担心这可能会导致数据完整性丢失。换句话说,没有任何东西防止状态被设置为“违约”,而没有支持更改的
EVENT
。这将完全由应用程序确保永远不会发生(我认为这个解决方案中没有引用完整性)。我的备选解决方案是放弃
LOANS
中的状态列,而是使用一个lastEvent
列,它是对EVENTS
的FK。然后,EVENTS
表将维护“类型”事件,该事件将进而描述状态更改(例如,如果lastEvent
是“payoff”类型,则自然状态为“paid”)。我的问题是:
1.我应该担心数据完整性吗(这是一个常见的事情,因此可以这样做)?
2.我的提议解决方案是否可靠,或者是否有更好的解决方案?
3.我的解决方案中是否存在任何陷阱,我应该注意?