数据库设计：有没有办法改进这个设计？
简单的问题 - 下面是保存以下记录的数据库设计
account TransactionType TransactionName Amount FeeTransactionId TransactionId RefTransactionId
Alex [Deposit from] [Credit Card x-1234] [-100.00] b a
Alex [Deposit from] [Credit Card Fee] [-3.00] b a
Alex [Added funds from] [Credit Card x-1234] [100.00] c a
Sys_ [Revenue from] [Credit Card Deposit] [3.00] d a
[Transaction]
Id
AccountId
TransactionTypeId
TransactionName
Amount
FeeTransactionId
RefTransactionId
[Account]
Id
Name
[TransactionType]
Id
Name
有没有办法改进此设计？
注意：缺少货币和日期。 :)
Simple question- Below is the database design to hold the following records
account TransactionType TransactionName Amount FeeTransactionId TransactionId RefTransactionId
Alex [Deposit from] [Credit Card x-1234] [-100.00] b a
Alex [Deposit from] [Credit Card Fee] [-3.00] b a
Alex [Added funds from] [Credit Card x-1234] [100.00] c a
Sys_ [Revenue from] [Credit Card Deposit] [3.00] d a
the design
[Transaction]
Id
AccountId
TransactionTypeId
TransactionName
Amount
FeeTransactionId
RefTransactionId
[Account]
Id
Name
[TransactionType]
Id
Name
Is there a way to improve on this design?
Note: currency and date is missing. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
乍一看还不错。
经过一番考虑，似乎每笔交易都链接到一个（且只有一个）其他交易，并且该链接的含义取决于交易类型。因此有两个自引用外键
FeeTransactionId和RefTransactionID。根据交易类型，这些键之一始终为 NULL。尽管在技术上可以在外键列中包含 NULL，但它可能不是首选做法。您只能有一个自引用外键，该外键不会有 NULL，如本模型所示。
At the first glance it looks ok.
After some consideration, seems that each transaction is linked to one (and only one) other transaction, and that the meaning of that link depends on the transaction type. Hence the two self-referencing foreign keys
FeeTransactionIdandRefTransactionID. Depending on type of the transaction, one of these keys is always NULL.Altough it is technically possible to have NULLs in a foreign key column, it may not be preffered practice. You could have only one self-referencing foreign key, which would not have NULLs, as in this model.
设计很好。很好而且标准化。不过，去规范化可能有充分的理由。通常这些涉及某种报告便利性或优化。如果没有有关该项目的更多详细信息，我真的无法提出任何更改建议。
The design is fine. Nice and normalized. There can be good reasons to de-normalize, though. Usually these involve some sort of reporting convenience or optimization. Without more details about the project, I really can't make any sort of recommendations for changes.