为什么我不能采用 RDBMS 数据库设计实践，并用于 NoSQL MongoDB 数据库设计？

Question

假设我有一个 BankAccount 表和一个 BankAccountHistoryTransactions 表。

当涉及到 RDBMS 数据库模式设计时，大多数数据库设计人员会推荐以下内容：

BankAccount Table

int: BankAccountNumber Primary key

double: CashBalance

......

..

此外，在 RDBMS 数据库设计中，BankAccountHistoryTransactions 表将类似于：

BankAccountHistoryTransactions Table

int: BankAccountHistoryTransactionsId Primary key

int: FK_BankAccountNumber Foreign key

DateTime2: DateOfTransaction

.................

.........

在 NoSQL MongoDB 数据库模式中，它更像是一个包含嵌入式 BankAccountHistoryTransactions 集合的 BankAccount 集合：

db.BankAccount.find().pretty()
{
    "_id" : ObjectId("51f7be1cd6189a56c399d3bf"),
    "BankAccountNumber" : "7575785885859",
    "CashBalance" : "890399",
....................................,
...............................,
.......................,
    "BankAccountHistoryTransactions" : {
        "_id" : ObjectId("51f7be1cd6189a56c399d3bf"),
        "BankAccountHistoryTransactionsId": 1,
        "DateOfTransaction" : ISODate("2019-12-31T23:00:00Z")

}
}

我对 NoSQL MongoDB 数据库架构设计方法的问题是银行账户可能有大量的 BankAccountHistoryTransactions 条目（可能进入银行账户的数十万个 BankAccountHistoryTransactions 条目）。

因此，如果我们使用如下所示的伪外键关系会不会更好：

    db.BankAccount.find().pretty()
    {
        "_id" : ObjectId("51f7be1cd6189a56c399d3bf"),
        "BankAccountNumber" : "7575785885859",
        "CashBalance" : "890399",
    ....................................,
    ...............................,
    .......................,
}

以及 BankAccountHistoryTransactions 的不同单独集合

db.BankAccountHistoryTransactions.find().pretty()
    {
        "_id" : ObjectId("51f7be1cd6189a56c399d3bf"),
        "FK_BankAccountNumber" : "7575785885859",
"BankAccountHistoryTransactionsId": 1,
            "DateOfTransaction" : ISODate("2019-12-31T23:00:00Z")

    }

我听说 NoSQL MongoDB 数据库设计者不鼓励使用像上面那样的伪外键关系。但是，像“伪外键关系”这样的设计不是更有条理、更模块化吗？（如果我错了，请纠正我，但性能可能是一个问题，但它肯定更有条理和模块化）

Answer 1

如果您想使用关系结构，并且您正在考虑使用 NoSQL 系统这样做，请使用 RDBMS，这就是它们的设计目的。

为工作使用正确的工具总是会带来更好的性能，并且没有人因为使用适合的 RDBMS 而不是使用没有意义的 NoSQL 解决方案而被解雇，例如在银行业务中需要 100% 保证一致性，而不是“最终一致性”。

在非关系数据库中使用关系代数只会让您在代码中复制关系功能，我可以保证您在这方面并不比 SQL Server 或 Oracle 强。