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

不使用外鍵

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

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

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

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

不使用級聯(lián)

SQL 數(shù)據(jù)庫允許用戶定義外鍵的級聯(lián)行為，以控制當有人更新或刪除父表中的行時會發(fā)生什么。

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

了解時區(qū)

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

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

使用行時間戳

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

認識演員

誰是演員?演員，小編的意思是改變系統(tǒng)中數(shù)據(jù)的人或服務。一個人可以使用提供的 UI 更改數(shù)據(jù)。服務可以在調(diào)度程序定期調(diào)用時修改數(shù)據(jù)。

您可能希望在每次數(shù)據(jù)更改時保留有關(guān)參與者的信息，至少用于日志和審計目的。根據(jù)產(chǎn)品要求和可用資源，您需要確定報告系統(tǒng)的準確性。

使用編號枚舉

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

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

限制列名長度

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

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

限制列值長度

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

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

對于實數(shù)，通常有三種可用類型：

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

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

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

存儲實數(shù)可能是一個挑戰(zhàn)，因為后端可能不支持與數(shù)據(jù)庫相同的精度標準。

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