數據庫設計
1、規範化android
數據庫規範化有一些規則。每一條規則都被稱爲「規範形式」。若是遵照第一條規則，則稱數據庫處於「第一範式」。
若是遵照前三條規則，則認爲數據庫處於「第三範式」。儘管能夠進行其餘級別的規範化，但第三種範式被認爲是大多數應用程序所必需的最高級別。
下面的描述包括一些示例。數據庫
第一範式cookie
- 消除單個表中的重複組。
- 爲每組相關數據建立一個單獨的表。
- 用主鍵標識每一組相關數據。
- 不要在一個表中使用多個字段來存儲相似的數據
上述記錄中的字段Class一、Class2和Class3表示設計問題數據庫設計
第二範式性能
- 爲應用於多個記錄的值集建立單獨的表。例如學生和老師的關係
- 將這些表與外鍵關聯。消除冗餘數據.
上述表中每一個學生的多個類值。Class#在功能上不依賴於Student（主鍵），拆表設計編碼
第三範式spa
- 消除不依賴於鍵的字段。
- 只對頻繁變化的數據應用第三範式可能更可行。
- 若是某些依賴字段仍然存在，請將應用程序設計爲在任何更改時要求用戶驗證全部相關字段。
規範化示例表設計
（源文連接：https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description）netty
2、數據類型orm
定義適當的屬性類型.能夠提升數據庫的性能，還能在存儲數據前驗證數據
咱們應該在「integer」、「numeric」字段中保存數值數據；在「timestamp」、「timestamptz」字段中保存時間戳；在「bit」、「char(1)」或「boolean」字段中保存布爾值等等。
日期值得特別注意。若是 Date 屬性假設只有日期部分（OrderDate，ReleaseDate），請使用沒有時間部分的 Date 類型。若是你只須要保留時間（StartTime，EndTime），就使用合適的時間類型。
若是不須要指定精度，則將其指定爲零（「time(0)」）。
對帶有時間部分的日期，有一個問題是，你必須老是截斷時間部分，只顯示日期，而且當你要在與數據庫所在時區不一樣的地方顯示時，要確保格式化後不會顯示成昨天或明天。
當跳轉到夏令時的時候，帶有時間部分的日期時間加減也可能出現問題
3、約束
將無效數據排除在外，並確保數據的健壯性
非空約束
業務規則要求該屬性應該始終存在，那麼要堅決果斷地將其設置爲 Not Null，其餘可選的信息字段可能仍是能夠設置爲 Null
一個典型的例子是，Employee 表的 ManagerId，並非全部員工都有經理。不要試圖讓 ManagerId 不爲空，併爲沒有經理的員工插入「0」或「-1」。當咱們添加外鍵約束時，這將致使其餘問題.
惟一約束
根據業務規則，一些屬性（或屬性的組合）應該是唯一的，好比 Id、PinNumber、BookId 和 AuthorId、OrderNo 等。應該經過添加唯一約束來保證這些屬性的唯一
主鍵
Not Null 和惟一約束一塊兒構成主鍵
當咱們想到主鍵時，會很快想到 Id 或 ObjectId 之類的列。可是主鍵也能夠是複合的，好比 BookId 和 AuthorId。
一般，使用單獨的 Id 列是一種更好的方法，由於它可使鏈接更加清晰，還能方便地將另外一列添加到唯一組合中。可是，即便有了一個單獨的主鍵（Id），咱們仍是要爲 BookId 和 AuthorId 列添加惟一約束
Check 約束
Check 約束容許咱們定義數據的有效值 / 範圍。適合 Check 約束的屬性有百分比（0 到 100 之間）、狀態（0、一、2）、價格、金額、總數（大於或等於 0）、PinNumber（固定長度）等。
不要嘗試將業務邏輯編碼到 Check 約束中
默認約束
默認約束也很重要。它們容許咱們向現有表中添加新的 Not Null 列
外鍵約束
外鍵約束是關係數據庫設計之王。外鍵與主鍵一塊兒確保表之間的數據一致性
索引
原文連接（https://relinx.io/2020/09/14/old-good-database-design/）
-
每一个你不满意的现在，都有一个你没有努力的曾经。