㈠ 說明在設計資料庫表時你是如何考慮的
資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計師所必須具備的基本素質條件！ 那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則： （1）、資料庫設計最起碼要佔用整個項目開發的40%以上的時間
資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。 （2）、資料庫設計不僅僅停留於頁面demo的表面 頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。 （3）、資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了 每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。 （4）、資料庫設計時就要考慮到效率和優化問題 一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。 （5）、添加必要的（冗餘）欄位 像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。 （6）、設計合理的表關聯 若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。 （7）、設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯 這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。 （8）、選擇合適的主鍵生成策略
㈡ 資料庫設計 多個表應該怎麼建立關系 需要注意哪些問題
相關聯的表要設置主鍵(父表)或外鍵(字表參照父表主鍵)，這樣就可以通過inner join ,left jion ,right join 進行連接例：父表student(int id primary key,varchar Name,varchar Sex) 字表selectbook(int student_id,varchar(20) bookName,varchar(20) author,date bookDate) 相應查詢select student.id,student.Name,selectbook.bookName,select.author from student left join selectbook on student.id=selectbook.student_id where student.Sex="Boy"
㈢ 資料庫分庫，分表有哪些要注意的以及解決辦法
資料庫設計的一個原則就是，一個庫里的表越少越好，一張表裡的欄位越少越好。當然也要看你的UI是怎麼設計的，如果一個頁面只查詢一張表，不涉及到多表連接，那麼無論放在哪個庫里都可以，那就建議分庫。否則就要跨表跨庫查詢，那真是噩夢！
㈣ 資料庫表的創建需要考慮什麼
欄位取有意義的英文單詞，下劃線拼接，要有comments
根據存儲的內容確定欄位類型，欄位長度
一般需要主鍵id，最好是數字，可以用自增長欄位
數據量怎麼樣，數據量大經常查詢的欄位要建索引
是否有唯一約束，唯一約束的欄位要建唯一索引
業務上還有是否要記錄創建人，創建時間，最後更新人，最後更新時間，是否需要邏輯刪除標志位，是否需要記錄版本做樂觀鎖控制
暫時想到這么多
㈤ 建資料庫表時 為欄位指定約束條件都需要注意些什麼
1.約束主要有一下幾種:
NOT NULL : 用於控制欄位的內容一定不能為空（NULL）。
UNIQUE : 控制項欄位內容不能重復，一個表允許有多個 Unique 約束。
PRIMARY KEY: 也是用於控制項欄位內容不能重復，但它在一個表只允許出現一個。
FOREIGN KEY: FOREIGN KEY 約束用於預防破壞表之間連接的動作，FOREIGN KEY 約束 2. 也能防止非法數據插入外鍵列，因為它必須是它指向的那個表中的值之一。
CHECK: 用於控制欄位的值范圍。
DEFAULT: 用於設置新記錄的默認值。
3. not null ： 用於控制欄位的內容一定不能為空（NULL）。
用法 ：Create table MyTable
(
id varchar(32) not null,
name varchar (32)
)
4. Primary Key ：也是用於控制項欄位內容不能重復，但它在一個表只允許出現一個。
在Sql Server、Orcale、MS Access 支持的添加Primary Key語法：
Create table myTB1
(
id nvarchar(32) not null primary key,
name nvarchar(32)
)
㈥ SQL Server2000創建表時應該注意什麼
Microsoft® SQL Server™ 2000
使用一組操作系統文件映射資料庫。資料庫中的所有數據和對象（如表、存儲過程、觸發器和視圖）都存儲在下列操作系統文件中：
主要
該文件包含資料庫的啟動信息，並用於存儲數據。每個資料庫都有一個主要數據文件。
次要
這些文件含有不能置於主要數據文件中的所有數據。如果主文件可以包含資料庫中的所有數據，那麼資料庫就不需要次要數據文件。有些資料庫可能足夠大故需要多個次要數據文件，或使用位於不同磁碟驅動器上的輔助文件將數據擴展到多個磁碟。
事務日誌
這些文件包含用於恢復資料庫的日誌信息。每個資料庫都必須至少有一個日誌文件。
例如，創建簡單的資料庫 sales
時，可以只使用一個包含所有數據和對象的主文件和一個包含事務日誌信息的日誌文件。另一種情況是，創建更復雜的資料庫 orders
時，可以使用一個主文件和五個輔助文件，資料庫內的數據和對象擴展到所有的六個文件中，另外有四個日誌文件包含事務日誌信息。
文件組允許對文件進行分組，以便於管理和數據的分配／放置。例如，可以分別在三個硬碟驅動器上創建三個文件（Data1.ndf、Data2.ndf
和 Data3.ndf），並將這三個文件指派到文件組 fgroup1 中。然後，可以明確地在文件組 fgroup1
上創建一個表。對表中數據的查詢將分散到三個磁碟上，因而性能得以提高。在
RAID（獨立磁碟冗餘陣列)條帶集上創建單個文件也可以獲得相同的性能改善。然而，文件和文件組使您得以在新磁碟上輕易地添加新文件。另外，如果資料庫超過單個
Microsoft Windows NT® 文件的最大大小，則可以使用次要數據文件允許資料庫繼續增長。
文件和文件組的設計規則
文件和文件組的設計規則包括：
文件或文件組不能由一個以上的資料庫使用。例如，文件 sales.mdf 和 sales.ndf 包含 sales
資料庫中的數據和對象，任何其它資料庫都不能使用這兩個文件。
文件只能是一個文件組的成員。
數據和事務日誌信息不能屬於同一文件或文件組。
事務日誌文件不能屬於任何文件組。
㈦ 建立資料庫時，對於表格的設計有些什麼原則
名單表：姓名、參與的工程項目、…… 項目表：工程項目、參與人員、…… 名單表裡的「參與的工程項目」就是項目表裡的「工程項目」，但一個人可以同時參加多個項目，並且時常會發生退出這個項目參加另一個項目的事件；項目表裡的「參與人員」也就是名單表裡的「姓名」，但一個項目會有多個人參加，並且參與人員會時常變動。 以上只是舉的一個例子，希望有高手指點表格設計應遵循的原則。
㈧ 一個好的資料庫要注意什麼
如果希望設計出比較好的資料庫，有一些專門的規則，稱為資料庫的設計範式。遵循這些規則，你將設計出良好的資料庫。下面將逐一對其進行說明：
1.第一範式：它的目標是確保每一列的原子性，如果每列（或屬性）都是不可再分的最小數據單元，則滿足第一範式。
2.第二範式：第二範式則是在第一範式的基礎上，更近一層，目標是確保表中的每一列都和主鍵相關。如果一個關系滿足第一範式，並且除了主鍵意外的其他列，都依賴與該主鍵，則滿足第二範式。例如：訂單表（訂單編號，產品編號，訂購日期，價格，。。。）;該表主要用來表述訂單，所以將訂單設為主鍵，而「訂購日期」，「價格」這兩列與「訂單編號」主鍵相關。但是「產品編號」並不依賴於「訂單編號」，該列應當刪除，放入產品表中。這樣，該表就之描述一件事情：訂單信息了。
3.第三範式：第三範式在第二範式的基礎上更近一層，目標是確保每列都和主鍵列直接相關，而不是間接相關，如果一個關系滿足第二範式，並且除了主鍵之外的其他列都不依賴與主鍵列，則滿足第三範式。
例如：訂單表（訂單編號，訂購日期，顧客編號，顧客姓名，..);初看該表沒有問題，滿足第二範式，單細看您會發現，「顧客姓名」和「顧客編號」又相關，最後經過傳遞依賴，「顧客姓名」和「訂單編號」相關。為了滿足第三範式，我們在設計資料庫的時候應該去掉「顧客姓名」列。
㈨ 在資料庫的建立過程中,多表的建立,有哪些注意點或者關鍵點。 請寫詳細些，多給分。
關鍵就是主鍵建立，把各表相關連，這樣好了。
你查詢時主鍵去關連，就很方便了
主鍵欄位就是主表中是唯一。
其它表引入主表的主鍵欄位就可以了