一、一般好的資料庫設計需要注意以下幾點
1、乙個好的資料庫設計首先要滿足使用者的需求
所有資訊系統最後都將提交給終端使用者使用，對於這一點，相信大家都已經達成共識。但是準確地把握使用者的需求是很難的，雖然
各方面的專家已經從不同方面給出了解決方案，但是使用者需求仍然是軟體工程中最不確定的因素之一。
2、乙個好的資料庫設計要便於維護和擴充
為了應對使用者需求的修改和新增，也為了滿足各種不同的軟硬體環境下系統的使用，大部分資訊系統都不得不在其生命期中進行公升
級和調整。在這些公升級、調整中，又有相當部分會涉及到資料庫設計的修改，因此，資料庫設計最好從一開始就能在易維護、可擴
充的角度多加斟酌。
（1）、不要為各種編號欄位的設定固定的意義
而是最好通過對照表來建立這種編號和意義的對照關係。舉例來說，很多設計者習慣給部門資訊給出固定的編號，這種設計有個致
命的缺陷：那就是由於這種對照關係既然不體現在資料庫中，就必然要用業務邏輯來進行解釋，這樣一來，一有新的調整就不得不
更新業務邏輯**，也就非常容易不一致的錯誤。
（2）、列舉資訊要體現在相應在對照表中
而不是體現在使用該資訊的表中的值字段，這樣做的好處是當使用者希望用該列舉資訊作為查詢條件的時候，通過參照表的方式可以
很容易的建立這些資訊，另外也避免了當多個**中都含有該列舉資訊有可能引起的不一致。
3、用關聯表建立表和表之間的多對多關係
而不要用乙個字段解析的方式進行，舉例來說，為了描述使用者(userinfo)和角色(roleinfo)之間的關聯關係，我們要建立對照表
userinfo_roleinfo，而不要試圖在使用者表中建立乙個較長的字段，如roles（用roleid1; roleid2...的形式構成）來代替，因為這
樣一來字段解釋需要在業務**相應的解析**，二來由於roles定長，無法滿足使用者角色的擴充。
3、乙個好的資料庫設計要具有「可讀性」
如同程式設計書籍中反覆強調的程式設計師一定要在**的可讀性方面下功夫一樣，考慮到資訊系統將來的公升級和維護可能要要由另外一批
人來進行，因此資料庫設計必然也要具有可理解性。
（1）、用設計文件來提高資料庫設計的可讀性
這點基本對應於「可讀性」**裡面的注釋。在乙個合格的資料庫設計文件中必須給出資料庫中的每個表、每個字段、表間的關聯
關係以及各種約束的意義以及由來，從而有可能讓開發者根據使用者需求和設計文件就能理解正確資料庫的設計。
（2）、給表和檢視起乙個有意義的名字
這點對應於coding規範中的變數和函式的命名，很顯然，customerinfo的名字很容易聯想到該表中含有客戶資訊，而把它命名為
table0001只能讓人感到費解外。另外，如果dbms提供表和檢視名的大小寫支援，該名稱最好由每個構成單詞（首字母大寫）拼接而
成。（3）、用字首給出表和檢視內容之外的其他資訊
如給參照表ref_字首，這樣就可以讓業務邏輯實現人員根據表的名字知道他所要操作的是不是張參照表，從而幫助他更快地理解詳
細設計，並有可能及早發現裡面的錯誤。同樣，給所有檢視加上v_字首，就可以讓業務邏輯程式設計者很容易地知道他現在面臨的是一
個表還是檢視，從而避免了對檢視進行更新操作這種低階的錯誤。
（4）、給每乙個欄位起乙個有意義的名字
如給customerinfo表中的電子郵件字段起名email讓人很容易明白它的準確含義，而field05則讓人不知所云。基於同樣的道理，數
據庫設計中也不能給字段起乙個張冠李戴的名字。
（5）、字段命名要考慮上下文
舉例來說，在userinfo表中，用username來表示使用者名字段就不如name來的更加合適。這種情況畫蛇添足的情況在對照表的設計中
體現得尤為明顯，如把部門對照表(ref_department)中的部門id欄位命名為departmentid，把部門名稱字段命名為departmentname
等等。（6）、檢視的設計不要牽扯到其他檢視
與**設計中函式呼叫最好不要巢狀過多層次相對應，為了便於資料庫設計的閱讀人能夠很好地理解設計，檢視最好直接建立在表
上。（7）、同一表中的記錄最好不要相互引用
這種引用關係不僅讓資料庫設計的閱讀人雲裡霧裡，也不便於業務邏輯**的編寫。
（8）、關聯表的命名用關聯的表名中間加下劃線連線構成
如學生(studentinfo)和課程(courseinfo)的關聯表起名studentinfo_courseinfo。
4、乙個好的資料庫設計能夠滿足空間和效率的要求
對於乙個資訊系統來說，在實現使用者需求的基礎之上，保證乙個較低的空間占用以及短的響應時間都是理智的客戶所願意看到的。
那麼在這一方面，資料庫設計又要做些什麼工作呢？
（1）、使用varchar而不要使用char欄位
對於不定長資訊如使用者的簡介資訊，varchar的使用可以減少近一半的空間占用。當然這點不能一概而論，如用相應長度的char儲存
定長文字資料就比varchar來的合適。
（2）、不要使用blob欄位存放「大資料」
blob欄位誠如其名，本身是為儲存二進位製大資料而出現的，同樣的道理也適用於某些dbms所引入的text欄位。因為對於一般資訊系
統而言，最長的字段往往是一些描述文字資訊，而dbms對char/varchar的長度基本能滿足這種需求。因此積極建議設計者對一些貌
似很長的文字的最大允許長度進行確認，在此基礎上參照dbms中的開發手冊來決定是否採用大字段。
（3）、不要使用設計器預設的字段長度
這種做法一方面縱容了設計者對使用者需求的一知半解以及對設計敷衍了事的不良習慣，另外一方面也在資料的儲存上浪費了不少的
空間，因為使用預設字段長度的情況往往發生在字段上。
（4）、不要輕易使用unicode文字字段
dbms對unicode的支援在幫助產品國際化的同時，也在一定程度上帶來空間上的浪費，尤其是在當要儲存的文字中的基本都是ascii
字元的情況下，這種浪費尤為明顯。因此，建議設計者在選擇unicode的理由，一定是出於國際化的考慮，而不是其他。因為大多數
的大字符集和ascii字元並存情況下所要碰到的問題基本上都已經由dbms提供商解決。
（5）、使用預計算表來提高響應速度
跟資料倉儲裡面的某些思路相似，當業務邏輯中需要用倒根據歷史資訊得來的統計資料時，最好由獨立於系統的預計算模組或相應
的dw工具定期完成這些統計資料的預計算。
5、乙個好的資料庫設計可以簡化業務邏輯的設計
所有的資料庫設計都不是孤立的，它通過相應的業務邏輯實現（三層結構中還有表現層）來形成最終的產品，因此乙個好的資料庫
設計應該能夠幫助降低業務邏輯的編寫難度，最起碼不要給業務邏輯的設計、編碼帶來額外工作。
（1）、所有允許為空的字段必須是基於使用者需求，而不是出於設計上方便的考慮。
這樣帶來的好處是讓詳細設計中的某些錯誤和疏漏（
如在設計中沒有考慮對非空字段的內容檢查）在編碼和單元測試階段就被發現，從而避免了進一步擴散，有助於提高軟體的質量。
（2）、不要業務邏輯**實現唯一性約束
對資料庫表中的某些字段（或者多個欄位的組合）的唯一性約束應該盡可能地加到資料庫端。因為這種約束工作交給業務邏輯中去
實現代價高昂而且不可靠。
（3）、關聯約束一定要建立在資料庫端
分析出設計中所涉及的主外來鍵引用關係並體現在資料庫設計中。這一條出於兩點考慮：降低業務邏輯的編寫難度和資料關聯性約束
的要求。
二、資料庫設計的幾個建議
1.使用明確、統一的標明和列名，例如 school, schoolcourse, courceid。
2.資料表名使用單數而不是複數，例如 studentcourse，而不是studentcourses。
3.資料表名不要使用空格。
4.資料表名不要使用不必要的字首或者字尾，例如使用school，而不是tblschool，或者schooltable等等。
5.資料庫中的密碼要加密，到應用中再解密。 （其實就是雜湊儲存、單向加密）
6.使用整數作為id欄位，也許現在沒有這個必要，但是將來需要，例如關聯表，索引等等。
7.使用整數欄位做索引，否則會帶來很大的效能問題 。
8.使用 bit 作為布林字段，使用整數或者varcha是浪費。同時，這類字段應該以「is」開頭。
9.要經過認證才能訪問資料庫，不要給每乙個使用者管理員許可權。
10.盡量避免使用「select *」，而使用「select [required_column_list]」以獲得更好的效能。
11.假如程式**比較複雜，使用orm框架，例如hibernate，ibatis。orm框架的效能問題可以通過詳細的配置去解決。
12.分割不常使用的資料表到不同的物理儲存以獲得更好的效能。
13.對於關鍵資料庫，使用安全備份系統，例如集群，同步等等。
14.使用外來鍵，非空等限制來保證資料的完整性，不要把所有的東西都扔給程式。
15.缺乏資料庫文件是致命的。你應該為你的資料庫設計寫文件，包括觸發器、儲存過程和其他指令碼。
16.對於經常使用的查詢和大型資料表，要使用索引。資料分析工具可以幫助你決定如何建立索引。
17.資料庫伺服器和網頁伺服器應該放在不同的機器上。這回提高安全性，並減輕cpu壓力。
18.image和blob欄位不應該定義在常用的資料表中，否則會影響效能。
19.正規化（normalization）要按照要求使用以提高效能。normalization做的不夠會導致資料冗餘，而過度normalization 會導致太多的join和資料表，這兩種情況都會影響效能。
20.多花點時間在資料庫設計上，否則你將來會付出加倍的時間來償還
SQL Server資料庫備份的幾個建議
1 定期進行資料備份 完備或差異備份 和日誌備份。2 使用壓縮備份來減少磁碟空間占用和提高備份效率。3 定期檢查磁碟剩餘空間和備份檔案增長情況，以確保有足夠空間進行下一次備份。4 使用校驗和 checksum 來檢查資料完整性。5 使用restore verifyonly來驗證備份可用性。6 根據資...
資料庫設計，建議規範
1 資料庫和表取名要有意義，最好不要超過32字元，命名都使用小寫字母或單詞並用下劃線隔開，字段最好不要有關鍵字等 2 臨時資料建議以tmp 為字首並以日期為字尾，備份資料建議以bak 為字首並以日期為字尾 3 資料庫和表的字符集統一使用utf8 表情用utfmb4 4 表和字段都要新增注釋 5 儲存...
資料庫設計的幾點建議
資料庫設計的幾點建議 1.表必須擁有識別符號。這是基本規則，每個表應該擁有唯一的行識別符號，以及可讓表的記錄和記錄間有所區別的列或列的集合。每個表都應該擁有乙個識別符號列，而且每條記錄的識別符號的值都是唯一的，此行識別符號稱為主鍵。2.表應該只儲存單一例項型別的資料。若在表中儲存太多資訊，可能導致無...