一、簡述
開發中必不可少的要與數據庫打交道，那麼優秀的數據庫設計則顯得尤其的重要。一個合理的數據庫結構可以爲當前開發及未來維護提供強有力的支撐。
什麼樣的數據庫結構才能稱得上優秀呢？個人的理解點是：
- 滿足需求
- 性能與冗餘（例：某需求，有一需頻繁訪問的查詢功能，查表A時需通過關聯ID訪問B表的對應名稱，那麼是否可以將B表名稱直接冗餘到A表中，減少頻繁的關聯查詢，增加查詢語句的性能）
- 預見性擴展需求（例1：目前只需要的"地址"字段，是否有必要改爲"國"+"省"+"市"+"區"+"詳細地址"組合字樣，以免後期需要根據區域統計分析業務；例2：未來可能的分庫分表時的標識設置、sql關聯等）
- 接近三大範式的理念
二、範式解析
說道數據庫設計，很多人都會想到三大範式。這裏我要說的是：三大範式只是一般設計數據庫的基本理念，可以建立冗餘較小、結構合理的數據庫；特殊情況要特殊對待，數據庫設計最重要的是看需求及性能，需求>性能>表結構。所以不能一味的去追求範式建立數據庫。
（先理解下，數據庫的"行"通常表示一個對象，"列"表示對象的屬性）
我們先來回顧一下三大範式，書面的術語就不復述，白話性的講述下：
範式一："列"原子性
即：不要1列對應多個屬性；且不要出現重複列屬性
範式二：屬性要依賴於"完全"主鍵
範式三：屬性要直接依賴於主鍵，不要間接依賴
三、設計矛盾體
a、如上：範式二與範式三的區別，若有很多店鋪或涉及店鋪業務時，需要展示店鋪對應站點的文字描述，我們直接將站點名稱冗餘到店鋪表中，採用範式二何嘗不可？可以減少頻繁的關聯查詢。
b、擴展：例如，現在店鋪只有阿里巴巴的平臺，但是可以預見的是馬上要多平臺的運營，什麼亞馬遜、eBay等等都會開設店鋪。那麼我們怎麼區分店鋪是屬於哪個平臺呢？事先加入platform_code字段標識平臺也是很方便的。
冗餘：
爲什麼我老是拿冗餘字段和擴展冗餘來說事呢，結合上面兩點：
a、假設現在有1000個平臺店鋪，每個店鋪每天銷售出100個訂單，那訂單表每天就會有10萬的數據生成。要不了多久，這個表就扛不住了，那咋辦呢？按平臺分表吧！之前的擴展冗餘是不是就起到作用了？！
a、隨着公司的發展，我們可能慢慢就會有物流系統、倉庫系統、店鋪數據中心、訂單系統等等平臺，然後自然而然的要進行分庫，部分庫中的數據就靠定時任務或者觸發同步數據了。
現在站點、店鋪分成了兩個系統，在不同的庫裏了，那鏈接查詢還方便嗎？此時字段冗餘是不是又給你解決了問題？！
注：開發中儘量的單表操作，業務關聯能上java交互的上java交互，可以爲系統的後期減少很多麻煩事！ZZZ...內容是不是跑偏了？