資料庫表設計

2021-09-02 17:49:31 字數 1939 閱讀 9444

在軟體的開發中,資料庫表的設計是十分基礎和重要的工作。資料庫表是軟體具體實現的基石,如果表設計的不合規範就會出現資料冗餘,跟業務脫節等問題,等出現問題後再做大的調整相應的依賴表的編碼測試等工作也會進行大的調整這樣就會造成極大的資源消耗。因此在專案一開始設計表的時候就要注意表設計的規範性問題。

資料庫、表、正規化

第一正規化(1nf)無重複的列

第二正規化(2nf)屬性完全依賴於主鍵 [ 消除部分子函式依賴 ]

第三正規化(3nf)屬性不依賴於其它非主屬性 [ 消除傳遞依賴 ]

鮑依斯-科得正規化(bcnf是3nf的改進形式)

這第三正規化的基礎上,資料庫表中不存在關鍵字段決定關鍵字段的情況。

後面的正規化都必須滿足前面的正規化

一對一乙個物件a對應乙個物件b

一對多乙個物件a對應乙個物件b

多對多物件a對應多個物件b,反過來物件b也對應多個物件a,多對多的關係通常需要有乙個中間表儲存兩張表的關係

商品展示頁面

spuspu(standard product unit):標準化產品單元。是商品資訊聚合的最小單位,是一組可復用、易檢索的標準化資訊的集合,該集合描述了乙個產品的特性。通俗點講,屬性值、特性相同的商品就可以稱為乙個spu。(商品的抽象概念,類似於物件導向的抽象類)

skusku=stock keeping unit(庫存量單位)。即庫存進出計量的基本單元,可以是以件,盒,托盤等為單位。(具體的商品)

從購物車到下訂單過程

1.外來鍵的使用

外來鍵是否使用主要看業務場景和開發成本

使用者量大,併發度高的比如網際網路行業不推薦使用外來鍵,使用外來鍵等於把事務的一致性檢查全部交給資料庫來完成,這些操作會帶來一筆資源消耗,因此資料庫的瓶頸很容易成為系統效能的瓶頸。尤其是受到io能力限制,不能輕易的水平擴充套件。若是把資料一致性的控制放到應用程式的事務中,讓應用伺服器承擔這部分的壓力,而應用伺服器一般都是可以輕鬆的做到水平擴充套件。

對於使用者量小的軟體,一般不會有資料庫的效能問題,使用外來鍵可以降低開發成本,因為資料庫幫開發人員省去檢查資料一致性的問題。

2.大表的設計

分片(sharding)

sharding是把大資料庫分成若干個碎片儲存在不同的物理節點上,屬於資料庫橫向擴充套件主要目的是為了突破單節點資料庫伺服器的i/o能力限制,解決資料庫擴充套件性問題。乙個shard可以包含多個表的內容甚至可以包含多個資料庫例項中的內容。每個shard被放置在乙個資料庫伺服器上。乙個資料庫伺服器可以處理乙個或多個shard的資料。系統中需要有伺服器進行查詢路由**,負責將查詢**到包含該查詢所訪問資料的shard或shards節點上去執行。

分表把一張表分成很多字表,分完以後大表只是乙個外殼,訪問資料在分表裡面。分表後,單錶的併發能力提高了,磁碟i/o效能也提高了。

分割槽把一張表的資料分成n個區塊儲存在磁碟上。分割槽突破了磁碟i/o瓶頸,提高了磁碟的讀寫能力。

分割槽的適用場景

1) 一張表的查詢速度已經慢到影響使用的時候。

2) 表中的資料是分段的

3)對資料的操作往往只涉及一部分資料,而不是所有的資料

分庫分庫是對資料庫進行拆分,提高資料庫寫入能力。

拆分資料庫表造成的問題

1)事務問題

在不同分割槽和分庫上,本地的資料庫事務管理功能無法管理到別的庫上。需要由資料庫中介軟體進行統一的管理。

2)跨庫跨表的join問題

在執行了分庫分表之後,難以避免會將原本邏輯關聯性很強的資料劃分到不同的表、不同的庫上,這時,表的關聯操作將受到限制,我們無法join位於不同分庫的表,也無法join分表粒度不同的表,結果原本一次查詢能夠完成的業務,可能需要多次查詢才能完成。常用的解決方法是根據業務特性進行資料異構,把常用的表聚合提前做好

資料庫表設計

什麼是設計三正規化 1.1 設計表的依據 按照這個三正規化設計的表不會出現資料冗餘 三正規化都有哪些 第一正規化 任何一張表都有乙個主鍵,並且每乙個字段原子性不可以再分 例子不滿足第一正規化 學生標號 學生姓名 001jaden zjl 123.com,13029199039 002haoyue w...

資料庫表設計

1 資料型別要合理 1 對於數字和日期型別,一般不要採用 varchar 型別,這個陷阱很容易被接受 1 容易帶來隱式型別轉換,導致索引失效,例如 where a 123 a 是varchar 列,實際儲存數字型別值 2 容易帶來資料質量的下降,例如日期型別 2019 01 23 2019 23 0...

資料庫模型設計 表設計

曾經何時,發現自己設計的表,根本不滿足業務發展。1.業務id的設計,如商品表,單錶就不說了,在如今海量資料的背景下,當然要分庫發表啦。商品表,id,item id,表位置,id當然就是主鍵了,在單錶情況下,保持唯一就可以。item id商品id,就是要在全域性保持唯一,可能商品表有30張,甚至100...