有時，理論與實踐有一些差距，在做一個具體的事情時，我們應該以實際為核心，而不是把理論死搬上來，要“從實際出發”，呵呵。
在數據庫的世界里存在着三大范式，也就是規范，真正的關系型數據庫應該盡可能的滿足這些規范，但有時，我們卻根據實際問題，需要違背這些規范，這個系列我將從實際項目中出發來與大家一起說說“反范式”的設計。
設計數據庫時，首先要根據業務，找出實體，確定實體間的關系。一個結構良好的數據庫，讓項目在開發的過程中可以順暢，而一個結構不穩定的數據庫則會導致項目在開發的過程中大量的修改代碼。不能滿面向對象的開閉原則（OCP）。有時，我們可能會經常為一些業務去添加表字段，而這並不是我提供的，建義大家，將新增的業務直接抽象成表對象，這樣可能避免原表對象的修改，而只是對原表在結構上進行了擴展，這是符合OCP的。
下面簡單介紹一下三大范式
1.第一范式（1NF）
在任何一個關系數據庫中，第一范式（1NF）是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系數據庫。
所謂第一范式（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。 如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一范式（1NF）中表的每一行只包含 一個實例的信息。例如，對於員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信 息，一個員工的信息在表中只出現一次。簡而言之，第一范式就是無重復的列。
2.第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式 （1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主 碼。
第二范式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和 主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡 而言之，第二范式就是非主屬性非部分依賴於主關鍵字。
3.第三范式（3NF）
滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數據庫表中不包含 已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在員工信息 表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它， 否則就會有大量的數據冗余。簡而言之，第三范式就是屬性不依賴於其它非主屬性。