在Java教程中大家會學到很多知識，設計原則就是其中一部分，那么，數據庫相關設計原則有哪些？動力節點小編來為大家解答。

不使用外鍵

在分布式系統的 SQL 數據庫中，外鍵可能會成為障礙。我們需要以特定順序對外鍵保存的記錄應用更改。請注意，并非所有 SQL 引擎都允許延遲一致性。允許在事務中進行不一致的更改不符合 SQL 標準。

一些開發人員通過使用可為空的外鍵來消除這種障礙。

此外，如果我們沒有很好地考慮我們的查詢，使用外鍵可能會導致死鎖!通過刪除外鍵，我們減少了死鎖的機會。

如果沒有外鍵，我們可以依靠正確使用的事務、隔離級別以及創建將數據庫從一個正確狀態移動到另一個正確狀態的正確查詢。

不使用級聯

SQL 數據庫允許用戶定義外鍵的級聯行為，以控制當有人更新或刪除父表中的行時會發生什么。

即使可以使用沒有外鍵的級聯，它也不會這樣做，因為級聯隱藏了用于更新和刪除的業務邏輯。

了解時區

可以說，人類在時間方面面臨的最大問題是時區。時區總是感覺含蓄，并且取決于地理環境，不包括臭名昭著的夏令時。

您可以使用 UTC 保存時間戳，因為它是獨立于位置和夏令時的全球標準。是使用專用類型還是僅使用整數定義的紀元時間取決于您。最后，所有與時間相關的操作都必須導致整數比較。

使用行時間戳

建議您知道數據庫中每一行(文檔)的創建、更新或刪除時間。您可以使用它來審計數據庫和調試。此外，您可以使用這些時間戳進行排序，尤其是對于沒有自然排序的實體。

認識演員

誰是演員?演員，小編的意思是改變系統中數據的人或服務。一個人可以使用提供的 UI 更改數據。服務可以在調度程序定期調用時修改數據。

您可能希望在每次數據更改時保留有關參與者的信息，至少用于日志和審計目的。根據產品要求和可用資源，您需要確定報告系統的準確性。

使用編號枚舉

在處理特定實體的狀態或狀態時，您可能傾向于將它們作為字符串保存在各自的數據庫字段中。它可以讓數據庫管理員輕松檢查這些值。另一個論點是您總是可以購買更多的磁盤空間。

事實可能介于兩者之間，因為小編認為使用Java整數類型需要精確規劃、節省空間(包括索引空間)并允許更快的比較。此外，在惡意獲取數據庫數據的情況下，它會向攻擊者隱藏部分業務邏輯。也就是說，我認為在產品的概念驗證階段使用基于字符的字段是合理的。

限制列名長度

小編相信您應該使列名盡可能短。小編發現編寫和閱讀簡潔的 SQL 查詢更容易。如果您一直發送大量查詢(您可能也希望為此使用內部存儲的過程)，那么您可能會因為名字太長而產生額外的流量。

在將列名放入每個寫入對象的 NoSQL 數據庫中，如果堅持使用長字符串，可能會浪費大量磁盤空間!

限制列值長度

根據經驗，您應該始終知道保存特定值需要多少空間。

數據庫引擎使用字節數而不是字符數來限制文本字段的長度。使用 Unicode 字符串時可能會令人驚訝。此外，您應該檢查文本列的編碼和排序規則——您可以在許多數據庫級別(整個數據庫、表或列)上應用這些屬性。

對于實數，通常有三種可用類型：

以 2 為底的浮點單精度類型，

浮點雙精度類型(使用與之前相同的基數)，

使用以 10 為底的固定精度。

存儲實數可能是一個挑戰，因為后端可能不支持與數據庫相同的精度標準。

使用整數時，我們需要在字段級別分配足夠的字節。我們應該決定是否支持簽名或未簽名數據。同樣，您的后端可能不支持與數據庫相同的整數標準。