我們大家都了解Oracle數據庫有很多的優點，但是你如果對其使用不當的話，是不能展現出它的優勢，以下就本人在Oracle開發的過程中所積累的相關經驗，以下的文章就是對相關內容的描述。
一、 Oracle數據庫設計中字段的使用
在一些表的設計中，有一些常用的這段，已經基本成為一個規范，在大型系統中，多可以看到這些字段的蹤影，當然字段的名字可能有所不同。常用的字段分為以下幾類：
1.WHO字段
這類字段多用於記錄每行記錄的操作變更信息，比如是誰添加的這行記錄，誰做過修改等，詳細說明如下：
字段名稱
類型
說明
- LAST_UPDATE_DATE
- DATE
最後修改日期
- LAST_UPDATED_BY
- NUMBER(15)
最後修改人
- CREATION_DATE
- DATE
創建日期
- CREATED_BY
- NUMBER(15)
創建人
I．創建人
在任何一個系統中，一般都會有一個權限驗證和登錄的過程，在登錄後，會在系統的內存中記錄登錄人的信息，當此人在對Oracle數據庫的某個表進行添加操作的時候，會同時把這個操作人員的ID值寫入表中，供後期統計及審計
II．創建時間
與創建人的含義類似，在創建的同時，寫入系統的當前時間，這個字段的值一般取自於服務器而不是客戶端，比如在Oracle中，可以直接使用SYSDATE作為這個字段的值
III．最後修改人
一條記錄被創建後，同樣會有被修改的可能性，這裡需要對修改的人進行一個記錄，以便於後期審計。
但是這裡要注意的是，這裡只記錄最後的修改信息，如果一條記錄經過多次的修改，中間的修改將無跡可尋，如果需要記錄詳細修改信息，需要使用日志功能，已經超出此字段的功效。
IV．最後修改日期
與最後修改人同時寫入記錄中，同理，也是記錄最後一次修改的時間，中間的修改均被最後一次覆蓋。
2． 狀態及有效期字段
在一些新聞類的內容中，經常會涉及到一個時效性，即一條新聞可能只在某一個時間段內是對外可見的，超過這個時間段則將不允許發布，還有就是有些時候如果發現某些內容有問題，需要暫時對外屏蔽的時候，就可以用到狀態字段，詳細說明如下：
字段名稱
類型
說明
STATUS
NUMBER
狀態
START_DATE
DATE
有效開始日期
END_DATE
DATE
有效結束日期
I．狀態
這個字段一般用數值型表達，0表示失效，1表示有效，當然在使用的時候，可以把這兩個值進行轉義，用“有效”和“失效”來顯示，不影響存儲方式。
失效不等於刪除，經過失效的內容，經過管理程序的調整，把狀態變成有效後，還可以恢復正常使用。
II．有效開始日期
這個字段如果填有具體的值，只有當時間超過這個時間後，信息才是有效的，在這個日期之前，信息將自動按無效處理，特別需要注意的是，如果這個字段置空，應該按跳過這個條件檢查來處理，這樣可以實現程序的靈活性。
III．有效結束日期
具體含義同上，只是超過此期，內容將按失效處理。
3．邏輯刪除
在Oracle數據庫系統中處理的刪除的做法一般有兩種：物理刪除和邏輯刪除，所謂物理刪除，就是在數據庫中直接使用delete等命令，從數據庫裡把數據真正的刪除，這種刪除從正常途徑將無法恢復數據，雖然可以部分程度減小整體的數據量，但不利於審計跟蹤；邏輯刪除指的是對數據不做任何刪除處理，而是對記錄打個標記，也就是在某個字段上賦值，表示此記錄已經刪除。
邏輯刪除的處理邏輯只由應用程序自己使用，因為數據在Oracle數據庫中實際還是存在的。
所涉及字段如下：
字段名稱
類型
說明
DELETED
NUMBER
是否刪除
DELETE_DATE
DATE
刪除時間
DELETED_BY
NUMBER
刪除人
I． 刪除標志
此字段有兩個取值,0表示正常，1表示已經刪除。
打上刪除標志後，所以的查詢語句必須同時在判斷條件的地方加上deleted=0的條件，否則會造成重大的失誤。
II． 刪除時間
與刪除標志一起使用，表示刪除的時間，可以使用當前服務器的時間，用sysdate來填充即可。
III． 刪除人
與最後修改人類似，需要記錄刪除的具體操作人員
刪除與標志位不同，采用標志位的方式，雖然前端無法展示數據，但是後台管理人員人一樣可以通過管理程序來調整該狀態，但是刪除標志則不同，確認刪除後，對整個應該來講，這條記錄都應該理解為不存在了。
4． 自增字段
所謂自增字段，是指隨著使用，它可以自動增加的字段。
這種字段的值一般沒有明確的含義，只用於一個唯一標識，這個字段一般也會設置成主鍵。
如果應用只針對Oracle，而不考慮數據庫無關性，那麼sequence無非是最好的一個選擇。對於以前用習慣MSSQL等其它數據庫的朋友來說，Oracle這種用法簡直是太費勁了，要花很大的功夫才能做好一個自增字段，但是正因為如此，它也帶來了其它Oracle數據庫不能相比的優點，舉例來說。
一個訂單系統，即有訂單頭，又有訂單行，一般是先插入訂單頭，再插入訂單行，對於MSSQL等數據庫的自增字段，只有插入後才知道具體的ID值是多少，那麼寫入後，還要返查一下這個字段值再給訂單行使用；而對於Oracle來說，只要先從sequence裡取出一個值來，頭和行一起使用即可，最主要是的sequence的效果是非常高的，不需要擔心性能問題。
5． 彈性字段
在Oracle數據庫表結構設計的時候，最好多留出幾個備用的字段來，因為隨著系統的使用，一般會有增加字段的需求。預留字段的好處是，只要需要的時候啟用即可，不需要進行DDL操作，對數據庫後期維護的風險很低，並且一般的DDL操作，會造成級聯的VIEW/PACKAGE等程序失效，預留了彈性字段，則不會有這個問題。
預留的字段也可以按類型分成三種：字符串型，數值型及日期型，可以每個類型預留10個，或根據需要來決定，可以采用如下的樣式：
- NUMBER_ATTRIBUTE1
- STRING_ATTRIBUTE1
- DATE_ATTRIBUTE1
彈性字段如果不啟用，會不會占用過多的存儲空間呢，答案是否定的，因為在這種大型Oracle數據庫的結構中，只有一個字段真正被用到的時候，才會去占用實際的空間，否則它只是一個“說明”，並不占用實際的空間，所以不會造成空間浪費。
6． 拆分字段
這並不是一個字段的類型，而是指在表設計的時候，可以適當的把一個大表拆成不同的小表來存儲，比如用戶表，可以包括登錄名，密碼，姓名，生日，等一系列的字段，在某些情況下，包括的會員屬性可能達到上百個之多。
在數據量小的時候，無論怎麼樣的存儲，都不會有性能問題，但是當數據量比較大的時候，就必須考慮性能問題。如果索引比較合理，不管數據量多大，一般查詢速度都不會太慢，但是當某些特別情況，不能使用索引的時候，就會產生FTS（所謂的全表掃描），那麼掃描一個小表和掃描一個大表所占的時間就完全不一樣了，所以建議比較大的表分開存儲，把常用的幾個字段單獨提取出來，這樣即便全表掃描，也能比較好的控制效率。
在使用的時候，只要主表和子表都有索引，把它們聯合起來查詢，和一個真正的大表的效果基本上是一樣的，雖然性能肯定比一個真實的大表慢一點，但是和另一方面的性能提升比較起來，是值得的。目前有些大的系統采用這種拆分方式
