為什麼我不能採用 RDBMS 數據庫設計實踐,並用於 NoSQL MongoDB 數據庫設計?
假設我有一個 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 數據庫設計人員不鼓勵使用上述偽外鍵關係。但是,類似“偽外鍵關係”的設計不是更有條理、更模組化嗎?(如果我錯了,請糾正我,但性能可能是個問題,但它肯定更有條理和模組化)
我不會說使用外鍵引用是“不鼓勵”。通常您使用 ObjectId 值作為參考。
您可以使用聚合 $lookup功能“加入”這些交易和銀行賬戶。
這是 MongoDB 模式設計的 6 條經驗法則。如何設計一對多關係
本系列文章應該回答您對這個問題的大部分擔憂。
如果您想使用關係結構,並且您正在考慮使用 NoSQL 系統這樣做,請使用 RDBMS,這就是它們的設計目的。
為工作使用正確的工具總是會帶來更好的性能,而且從來沒有人因為使用適合的 RDBMS 而不是使用沒有意義的 NoSQL 解決方案而被解僱,例如在銀行情況下,您需要 100% 保證一致性,而不是“最終一致性”。
在非關係數據庫中使用關係代數只會讓你在程式碼中複製關係功能,我可以保證你在這方面並不比 SQL Server 或 Oracle 更好。