這篇部落格會記錄在實戰中對資料庫表業務設計對經驗，因為接觸到到專案水平有限，所以經驗僅供參考，記錄下來，作為自己到收穫，也希望可以幫助到有用的人。
在業務改動與設計中，要增加乙個字段，如何判斷該欄位應該新增在**呢？之前的一段時間，老是喜歡加在主表中，把主表做的「又大又肥」，這種方式的好處比較直接，返回的資料是大雜燴，啥都有。但是問題也很明顯，會產生維護災難，後期的維護會很難進行。還需要考慮的乙個點就是對某欄位可能產生業務擴充套件擴充套件，也就是所說的需求更改，會不會增加很多該字段的聯絡字段？出於這種角度考慮，新增新字段的時候，如果業務上情形比較複雜，並且會關聯到其他介面的情況下，還是用子表進行附加會比較靈活。
總結：在表設計中，要靈活對一張大表進行拆分，從資料庫設計的角度模組化，一張抽象表，掛很多特徵表，需要擴充套件就繼續掛特徵表，比較容易擴充套件與維護。個人感覺這個思路非常好。
這兩個概念是自己在專案中創造的，怎麼理解呢？舉個例子來說，如果**賣一種產品，這種產品有四種體現，各有特徵字段，那是不是意味著必須設計四張表來表示呢？假設我們按照這個思路，可能有4種controller，4種service…,如果出現產品的型別增加，也是有特徵欄位的，天吶！那維護肯定是個災難了。面對這種情況，我提出了抽象表與具象表的設計。
所謂抽象表何解呢？還是用上面那個例子，一種產品，四種具體的型別，我們設計一張通用product表，裡面有公共字段，比如產品名字這種，總該都有吧！然後呢？重點來了，在product表中設計乙個type列舉類，標記這種產品屬於哪種型別，如果型別實在太多，可以通過type表來管理。然後以product表為抽象表，對不同對產品，設計具體對具象表，通過productid來與抽象表產生關係，這種設計非常鬆散，擴充套件性從個人的角度也是十分好的，推薦給可能需要的朋友！
資料庫設計 1
一,根據entity建立relationship。需求分析 獲取資料 根據資料資訊建立資料模型,畫er圖或uml。建立資料之間的關係。將資料模型轉換為sql表 二 應該遵循合理的資料庫正規化,以降低資料冗餘 保證資料的完整性和正確性。提高系統的可維護性,擴充套件性。1,不可再分,以位址為例 位址應該...
資料庫表設計
在軟體的開發中，資料庫表的設計是十分基礎和重要的工作。資料庫表是軟體具體實現的基石，如果表設計的不合規範就會出現資料冗餘，跟業務脫節等問題，等出現問題後再做大的調整相應的依賴表的編碼測試等工作也會進行大的調整這樣就會造成極大的資源消耗。因此在專案一開始設計表的時候就要注意表設計的規範性問題。資料庫 ...
資料庫表設計
什麼是設計三正規化 1.1 設計表的依據 按照這個三正規化設計的表不會出現資料冗餘 三正規化都有哪些 第一正規化 任何一張表都有乙個主鍵，並且每乙個字段原子性不可以再分 例子不滿足第一正規化 學生標號 學生姓名 001jaden zjl 123.com,13029199039 002haoyue w...