我希望能挖掘到這裏的一些集體的經驗，所以什麼（如果有的話）實用程序表，或共同領域你始終在你的數據庫設計？數據庫表/領域應用程式
一個例子是，我總是包括App_Errors表來存儲任何未捕獲的異常信息，並存儲所有的編輯信息的App_Audit表。
我已經在每個數據表上提出了包括RecordCreatedDate和RecordLastEditedDate在內的益處，但沒有得出關於信息是否真的有用的結論。
爲了給問題多一點的方向 - 我目前的工作重點是全球可訪問的Web應用程序（認爲社交網絡）。
Ta！
1包含一個版本號，這樣應用程序可以很容易地檢查架構的版本表。
2所述的表來保存任意變量/值對，例如一個配置文件，但在數據庫中。 （你可以把版本號在這裏....）
每個表，無論它做什麼，總是以「ID」字段開始，詮釋。
我還保存一個錯誤表，其中包括ID，日期時間，不合格方法和過載，和棧跟蹤（如果可用）。
有時候，我有一個設置/統計數據表格，但並非總是如此。
我經常使用一個審計日誌表來跟蹤哪些數據已被更改以及由誰。
你會在它如何定期一直是巨大的好處感到驚訝。
在我工作的幾乎每個數據模型中出現的其他內容都是狀態表上的變體，通常與主實體的狀態生命週期有關。
具有錯誤代碼，技術信息，用戶信息，嚴重程度和備忘錄列的錯誤消息表。嚴重性和用戶消息用於在發生錯誤時構建消息對話框。記錄錯誤時，錯誤代碼和技術消息包含在錯誤日誌中（以及客戶端的IP，日期，時間等）。
對於報告，一個數字表（0到1Mil的整數）和一個靜態日期表（30天的價值天）。
我傾向於始終有一個表，列出所有可以訪問系統的用戶。我更喜歡通過爲連接池原因爲每個人創建一個單獨的數據庫用戶。
則一般上市角色的人可以在系統的表。連接表指示誰可以做什麼。對於商業領域中的應用程序特定規則，這種設置通常會變得更加複雜。
審覈表是一個很好的主意。我加入了一個可讀的專欄，以便非技術人員有機會弄清楚發生了什麼，以及存儲各種鍵和重要的值。
我覺得這是送花兒給人方便，包括以下字段：
就使得它很容易爲 '軟刪除'因此數據完整性得到維護，您不會失去寶貴的歷史信息。
和Galwegian提到的審計日誌表+1。
成員資格表。無價。
保存用戶數據（與您的系統數據相反）的任何表都具有創建日期和上次更新日期。如果有1％的機會，你可能需要知道什麼時候發生了什麼事情。這將在未來節省很多麻煩。雖然我不喜歡觸發器，但使用它們來維護這兩個字段是值得的。如果你使用真正的數據庫登錄，那麼created_user和updated_user也是有用的。
點2的+1。我傾向於稱之爲「屬性」。第1點也是有效的。 – Draemon 2008-12-16 22:49:39
我會補充說，任意var/val表的作用更好，因爲類別/ var/val表。 – jmucchiello 2009-01-20 07:27:42
我有一個名爲「schema_version」的表。每次數據庫升級都會在該表中插入一個包括版本號，說明和系統日期的表。 – 2009-01-20 21:58:23