論壇資料庫設計

⑴ 做論壇對於視頻文件如何儲存,資料庫庫如何設計

1、正常創一個文件信息表，主鍵，文件名，文件真實名，文件存儲路徑，文件類型，關晌如冊橡棗聯表id，上傳時間。

2、存在資料庫中的肯定是文件的存儲路徑。取得時候就是通過路徑去取。

3、你上傳視頻文件，資料庫保存文件名字，路徑

4、全部轉換宴宏成二進制，存到資料庫中，或者存為url

⑵ 資料庫如何設計

資料庫設計的基本步驟

按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下6個階段

1.需求分析

2.概念結構設計

3.邏輯結構設計

4.物理結構設計

5.資料庫實施

6.資料庫的運行和維護

資料庫設計通常分為6個階段1分析用戶的需求，包括數據、功能和性能需求；2概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖；3邏輯結構設計：通過將轉換成表，實現從E-R模型到關系模型的轉換；4：主要是為所設計的資料庫選擇合適的和存取路徑；5資料庫的實施：包括編程、測試和試運行；6資料庫運行與維護：系統的運行與資料庫的日常維護。）,主要討論其中的第3個階段,即邏輯設計。

在資料庫設計過程中，需求分析和概念設計可以獨立於任何資料庫管理系統進行，邏輯設計和物理設計與選用的DAMS密切相關。

1.需求分析階段（常用自頂向下）

進行資料庫設計首先必須准確了解和分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，也是最困難，最耗時的一步。需求分析是否做得充分和准確，決定了在其上構建資料庫大廈的速度與質量。需求分析做的不好，會導致整個資料庫設計返工重做。

需求分析的任務，是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求，然後在此基礎上確定新的系統功能，新系統還得充分考慮今後可能的擴充與改變，不僅僅能夠按當前應用需求來設計。

調查的重點是，數據與處理。達到信息要求，處理要求，安全性和完整性要求。

分析方法常用SA(Structured Analysis) 結構化分析方法，SA方法從最上層的系統組織結構入手，採用自頂向下，逐層分解的方式分析系統。

數據流圖表達了數據和處理過程的關系，在SA方法中，處理過程的處理邏輯常常藉助判定表或判定樹來描述。在處理功能逐步分解的同事，系統中的數據也逐級分解，形成若干層次的數據流圖。系統中的數據則藉助數據字典（data dictionary，DD）來描述。數據字典是系統中各類數據描述的集合，數據字典通常包括數據項，數據結構，數據流，數據存儲，和處理過程5個階段。

2.概念結構設計階段（常用自底向上）

概念結構設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合，歸納與抽象，形成了一個獨立於具體DBMS的概念模型。

設計概念結構通常有四類方法：

• 自頂向下。即首先定義全局概念結構的框架，再逐步細化。

• 自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。

• 逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。

• 混合策略。即自頂向下和自底向上相結合。

3.邏輯結構設計階段（E-R圖）

邏輯結構設計是將概念結構轉換為某個DBMS所支持的數據模型，並將進行優化。

在這階段，E-R圖顯得異常重要。大家要學會各個實體定義的屬性來畫出總體的E-R圖。

各分E-R圖之間的沖突主要有三類：屬性沖突，命名沖突，和結構沖突。

E-R圖向關系模型的轉換，要解決的問題是如何將實體性和實體間的聯系轉換為關系模式，如何確定這些關系模式的屬性和碼。

4.物理設計階段

物理設計是為邏輯數據結構模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。

首先要對運行的事務詳細分析，獲得選擇物理資料庫設計所需要的參數，其次，要充分了解所用的RDBMS的內部特徵，特別是系統提供的存取方法和存儲結構。

常用的存取方法有三類：1.索引方法，目前主要是B+樹索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。

5.資料庫實施階段

資料庫實施階段，設計人員運營DBMS提供的資料庫語言（如sql）及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編制和調試應用程序，組織數據入庫，並進行試運行。

6.資料庫運行和維護階段

資料庫應用系統經過試運行後，即可投入正式運行，在資料庫系統運行過程中必須不斷地對其進行評價，調整，修改。

資料庫設計5步驟
Five Steps to design the Database

1.確定entities及relationships

a)明確宏觀行為。資料庫是用來做什麼的？比如，管理雇員的信息。

b)確定entities。對於一系列的行為，確定所管理信息所涉及到的主題范圍。這將變成table。比如，僱用員工，指定具體部門，確定技能等級。

c)確定relationships。分析行為，確定tables之間有何種關系。比如，部門與雇員之間存在一種關系。給這種關系命名。

d)細化行為。從宏觀行為開始，現在仔細檢查這些行為，看有哪些行為能轉為微觀行為。比如，管理雇員的信息可細化為：

· 增加新員工

· 修改存在員工信息

· 刪除調走的員工

e)確定業務規則。分析業務規則，確定你要採取哪種。比如，可能有這樣一種規則，一個部門有且只能有一個部門領導。這些規則將被設計到資料庫的結構中。

====================================================================
範例：
ACME是一個小公司，在5個地方都設有辦事處。當前，有75名員工。公司准備快速擴大規模，劃分了9個部門，每個部門都有其領導。
為有助於尋求新的員工，人事部門規劃了68種技能，為將來人事管理作好准備。員工被招進時，每一種技能的專業等級都被確定。


定義宏觀行為
一些ACME公司的宏觀行為包括：
● 招聘員工
● 解僱員工
● 管理員工個人信息
● 管理公司所需的技能信息
● 管理哪位員工有哪些技能
● 管理部門信息
● 管理辦事處信息
確定entities及relationships
我們可以確定要存放信息的主題領域(表)及其關系，並創建一個基於宏觀行為及描述的圖表。
我們用方框來代表table，用菱形代表relationship。我們可以確定哪些relationship是一對多，一對一，及多對多。
這是一個E-R草圖，以後會細化。



細化宏觀行為
以下微觀行為基於上面宏觀行為而形成：
● 增加或刪除一個員工
● 增加或刪除一個辦事處
● 列出一個部門中的所有員工
● 增加一項技能
● 增加一個員工的一項技能
● 確定一個員工的技能
● 確定一個員工每項技能的等級
● 確定所有擁有相同等級的某項技能的員工
● 修改員工的技能等級

這些微觀行為可用來確定需要哪些table或relationship。

確定業務規則
業務規則常用於確定一對多，一對一，及多對多關系。
相關的業務規則可能有：
● 現在有5個辦事處；最多允許擴展到10個。
● 員工可以改變部門或辦事處
● 每個部門有一個部門領導
● 每個辦事處至多有3個電話號碼
● 每個電話號碼有一個或多個擴展
● 員工被招進時，每一種技能的專業等級都被確定。
● 每位員工擁有3到20個技能
● 某位員工可能被安排在一個辦事處，也可能不安排辦事處。

2.確定所需數據

要確定所需數據：

a)確定支持數據

b)列出所要跟蹤的所有數據。描述table(主題)的數據回答這些問題：誰，什麼，哪裡，何時，以及為什麼

c)為每個table建立數據

d)列出每個table目前看起來合適的可用數據

e)為每個relationship設置數據

f)如果有，為每個relationship列出適用的數據

確定支持數據

你所確定的支持數據將會成為table中的欄位名。比如，下列數據將適用於表Employee，表Skill，表Expert In。

Employee

Skill

Expert In

ID

ID

Level

Last Name

Name

Date acquired

First Name

Description

Department

Office

Address


如果將這些數據畫成圖表，就像：



• 需要注意：


• ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。


• ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。


• ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。


• ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。


• ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。

3.標准化數據

標准化是你用以消除數據冗餘及確保數據與正確的table或relationship相關聯的一系列測試。共有5個測試。本節中，我們將討論經常使用的3個。
關於標准化測試的更多信息，請參考有關資料庫設計的書籍。

標准化格式
標准化格式是標准化數據的常用測試方式。你的數據通過第一遍測試後，就被認為是達到第一標准化格式；通過第二遍測試，達到第二標准化格式；通過第三遍測試，達到第三標准化格式。

如何標准格式：
1． 列出數據
2． 為每個表確定至少一個鍵。每個表必須有一個主鍵。
3． 確定relationships的鍵。relationships的鍵是連接兩個表的鍵。
4． 檢查支持數據列表中的計算數據。計算數據通常不保存在資料庫中。
5． 將數據放在第一遍的標准化格式中：
6． 從tables及relationships除去重復的數據。
7． 以你所除去數據創建一個或更多的tables及relationships。
8． 將數據放在第二遍的標准化格式中：
9． 用多於一個以上的鍵確定tables及relationships。
10． 除去只依賴於鍵一部分的數據。
11． 以你所除去數據創建一個或更多的tables及relationships。
12． 將數據放在第三遍的標准化格式中：
13． 除去那些依賴於tables或relationships中其他數據，並且不是鍵的數據。
14． 以你所除去數據創建一個或更多的tables及relationships。

數據與鍵
在你開始標准化（測試數據）前，簡單地列出數據，並為每張表確定一個唯一的主鍵。這個鍵可以由一個欄位或幾個欄位（連鎖鍵）組成。

主鍵是一張表中唯一區分各行的一組欄位。Employee表的主鍵是Employee ID欄位。Works In relationship中的主鍵包括Office Code及Employee ID欄位。給資料庫中每一relationship給出一個鍵，從其所連接的每一個table中抽取其鍵產生。

RelationShip

Key

Office

*Office code

Office address

Phone number

Works in

*Office code

*Employee ID

Department

*Department ID

Department name

Heads

*Department ID

*Employee ID

Assoc with

*Department ID

*EmployeeID

Skill

*Skill ID

Skill name

Skill description

Expert In

*Skill ID

*Employee ID

Skill level

Date acquired

Employee

*Employee ID

Last Name

First Name

Social security number

Employee street

Employee city

Employee state

Employee phone

Date of birth


將數據放在第一遍的標准化格式中
● 除去重復的組
● 要測試第一遍標准化格式，除去重復的組，並將它們放進他們各自的一張表中。
● 在下面的例子中，Phone Number可以重復。（一個工作人員可以有多於一個的電話號碼。）將重復的組除去，創建一個名為Telephone的新表。在Telephone與Office創建一個名為Associated With的relationship。

將數據放在第二遍的標准化格式中
● 除去那些不依賴於整個鍵的數據。
● 只看那些有一個以上鍵的tables及relationships。要測試第二遍標准化格式，除去那些不依賴於整個鍵的任何數據（組成鍵的所有欄位）。
● 在此例中，原Employee表有一個由兩個欄位組成的鍵。一些數據不依賴於整個鍵；例如，department name只依賴於其中一個鍵（Department ID）。因此，Department ID，其他Employee數據並不依賴於它，應移至一個名為Department的新表中，並為Employee及Department建立一個名為Assigned To的relationship。


將數據放在第三遍的標准化格式中
● 除去那些不直接依賴於鍵的數據。
● 要測試第三遍標准化格式，除去那些不是直接依賴於鍵，而是依賴於其他數據的數據。
● 在此例中，原Employee表有依賴於其鍵（Employee ID）的數據。然而，office location及office phone依賴於其他欄位，即Office Code。它們不直接依賴於Employee ID鍵。將這組數據，包括Office Code，移至一個名為Office的新表中，並為Employee及Office建立一個名為Works In的relationship。

4.考量關系

當你完成標准化進程後，你的設計已經差不多完成了。你所需要做的，就是考量關系。

考量帶有數據的關系
你的一些relationship可能集含有數據。這經常發生在多對多的關系中。

遇到這種情況，將relationship轉化為一個table。relationship的鍵依舊成為table中的鍵。

考量沒有數據的關系
要實現沒有數據的關系，你需要定義外部鍵。外部鍵是含有另外一個表中主鍵的一個或多個欄位。外部鍵使你能同時連接多表數據。

有一些基本原則能幫助你決定將這些鍵放在哪裡：

一對多在一對多關系中，「一」中的主鍵放在「多」中。此例中，外部鍵放在Employee表中。

一對一在一對一關系中，外部鍵可以放進任一表中。如果必須要放在某一邊，而不能放在另一邊，應該放在必須的一邊。此例中，外部鍵（Head ID）在Department表中，因為這是必需的。

多對多在多對多關系中，用兩個外部鍵來創建一個新表。已存的舊表通過這個新表來發生聯系。

5.檢驗設計

在你完成設計之前，你需要確保它滿足你的需要。檢查你在一開始時所定義的行為，確認你可以獲取行為所需要的所有數據：
● 你能找到一個路徑來等到你所需要的所有信息嗎？
● 設計是否滿足了你的需要？
● 所有需要的數據都可用嗎？
如果你對以上的問題都回答是，你已經差不多完成設計了。

最終設計
最終設計看起來就像這樣：

設計資料庫的表屬性
資料庫設計需要確定有什麼表，每張表有什麼欄位。此節討論如何指定各欄位的屬性。

對於每一欄位，你必須決定欄位名，數據類型及大小，是否允許NULL值，以及你是否希望資料庫限制欄位中所允許的值。

選擇欄位名
欄位名可以是字母、數字或符號的任意組合。然而，如果欄位名包括了字母、數字或下劃線、或並不以字母打頭，或者它是個關鍵字（詳見關鍵字表），那麼當使用欄位名稱時，必須用雙引號括起來。

為欄位選擇數據類型
SQL Anywhere支持的數據類型包括：
整數（int, integer, smallint）
小數（decimal, numeric）
浮點數（float, double）
字元型（char, varchar, long varchar）
二進制數據類型（binary, long binary）
日期/時間類型（date, time, timestamp）
用戶自定義類型

關於數據類型的內容，請參見「SQL Anywhere數據類型」一節。欄位的數據類型影響欄位的最大尺寸。例如，如果你指定SMALLINT，此欄位可以容納32,767的整數。INTEGER可以容納2,147,483,647的整數。對CHAR來講，欄位的最大值必須指定。

長二進制的數據類型可用來在資料庫中保存例如圖像(如點陣圖)或者文字編輯文檔。這些類型的信息通常被稱為二進制大型對象，或者BLOBS。

關於每一數據類型的完整描述，見「SQL Anywhere數據類型」。

⑶ 如何設計合理高效的資料庫

一、 引言資料庫對於企業信息化的重要性是不言而喻的。資料庫存儲著現代企業最重要的數據，包括生產、經營、管理等各類數據，這些數據作為企業的核心信息，通過各類信息系統，為用戶提供及時准確的信息，幫助用戶分析，為用戶提供決策依據。為提高企業的工作效率，提升企業形象，具有傳統模式無法比擬的優勢。其中構建合理高效的資料庫，是資料庫建設關鍵之一。如何構建合理高效的資料庫是企業信息化過程要解決的問題。下面就資料庫的構建談談自己的一些經驗，希望能對大家有所幫助。 二、 設計資料庫之前
資料庫並不是憑空想像出來的，而是根據業務部門的需要設計符合業務需求的資料庫。因此在形成資料庫之前需要充分了解業務需求。 1. 充分理解業務需求。需求分析是整個設計過程的基礎，是最困難、最耗費時間的一步。在這期間通過與業務部門交流，了解用戶的想法以及工作流程，通過雙方多次交流，會形成初步的數據模型，當然這時的數據模型不會是最終的模型，還需要和用戶進行交流，並且在以後的信息系統開發過程中還會反復修改。 2. 重視輸入輸出。在定義資料庫表和欄位需求（輸入）時，首先應了解數據產生源和數據流程，也就是必需要知道每個數據在那兒產生，數據在那兒表現，以什麼樣的形式表現等等，然後根據用戶提供的報表或者設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。 3. 創建數據字典和ER 圖表。ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。 需要注意的是，在需求分析調研過程中，並不是一帆風順的，因為業務人員對於業務的理解不同，以及對於信息知識的缺乏，會影響需求分析的質量，為了提高質量，各方要用更多的時間交流與相互理解，業務部門需要精通業務的人員自始至終全力配合，而開發人員則盡量使用用戶理解的業務術語交流，這樣會避免出現理解不同而產生的歧義。 三、 設計合理的表結構
通常合理的表結構會減少數據冗餘，提高資料庫的性能。設計合理的表結構要遵循以下兩點。 1. 標准化和規范化 數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但3NF(第三範式)通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF標準的資料庫的表設計原則是：某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。 例如：某個存放單井信息及其有關油井生產日報信息的3NF資料庫就有兩個表：單井基礎信息和油井日報信息。日報信息不包含單井的任何信息，但表內會存放一個鍵值，該鍵指向單井基礎信息里包含該油井信息的那一行。 不過也有例外，有時為了效率的緣故，對表不進行標准化也是必要的。 2. 考慮各種變化 在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。使資料庫更具擴展性，從而減少將來數據變更所帶來的損失。 例如，日期類型欄位，有時我們會考慮使用字元類型代替日期類型，因為在處理日期欄位上容易產生數據錯誤，所以我們就使用字元類型。這樣的例子還很多，在做前期設計時都要考慮的。 表結構的設計不是一次就能成功的，在信息系統開發過程中會存在數據讀取、錄入或統計困難，為了解決這些問題會修改表結構，或增加一些欄位，或修改一些欄位的屬性。這個過程不斷重復，因此不要想一次能成功。建議使用專門設計工具來做這些工作，筆者經常使用：SYBASE PowerDesigner ，當然還有其它的工具：ORACLE Designer 2000 ，ROSE等工具。這樣會使你的工作事半功倍。 四、 選擇合理的索引
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。 1. 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。 2. 大多數資料庫都索引自動創建的主鍵欄位，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。 3. 不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的存儲空間。如MEMO(備注)、TEXT(文本)等欄位。 4. 不要索引常用的小型表 不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。如代碼表，或系統參數表。 五、 保證數據完整性
數據的完整性非常重要，這關繫到數據的准確性，不準確的數據是毫無價值的，因此保證數據的完整性非常重要。 1. 完整性實現機制：實體完整性：主鍵參照完整性： 父表中刪除數據：級聯刪除；受限刪除；置空值父表中插入數據：受限插入；遞歸插入 父表中更新數據：級聯更新；受限更新；置空值 DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制用戶定義完整性：NOT NULL；CHECK；觸發器 以上完整性機制需要熟悉和掌握，它對於數據的完整性非常重要。 2. 用約束而非業務規則強制數據完整性 採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於業務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。 3. 強制指示完整性 在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。 4. 使用查找控制數據完整性 控制數據完整性的最佳方式就是限制用戶的錄入。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：性別代碼、單位代碼等。 5. 採用視圖 視圖是一個虛擬表，其內容由SQL語句定義，視圖不僅可以簡化用戶對數據的理解，也可以簡化他們的操作。那些被經常使用的查詢可以被定義為視圖，從而使得用戶不必為以後的操作每次指定全部的條件。另外通過視圖用戶只能查詢和修改他們所能見到的數據。資料庫中的其它數據則既看不見也取不到。資料庫授權命令可以使每個用戶對資料庫的檢索限制到特定的資料庫對象上，增強數據的安全性。 六、 結束語
資料庫的高效運行不僅需要技術上的支持，也需要硬體平台和網路的支持以及資料庫管理員的有效管理，本文只是從技術的角度說明如何提高資料庫的效率，但在實際應用過程中其它方面的支持也是不可缺少的，尤其是資料庫管理，資料庫建設是「三分技術，七分管理，十二分基礎數據」，因此對於資料庫管理一定要重視，在管理到位的情況下技術才能發揮應有的作用。

⑷ 論壇的資料庫怎麼設計

常用的論壇設計方法，總結如下：
一 分割思想：
1 資料庫切分：用戶庫、主題庫、回復庫
2 數據表水平切分：用戶庫1-n、主題庫1-n、回復庫1-n （比如按時間分）
3 分布式資料庫：每台計算機中都有DBMS的一份完整拷貝副本，並具有自己局部的資料庫，位於不同地點的許多計算機通過網路互相連接，共同組成一個完整的、全局的大型資料庫。
4 論壇功能可以進行分隔，不同的伺服器負責不同的功能
5 用主從資料庫，master是寫， slave是讀
6 把內容與其它信息分開，好處就是可以讓每個表的文件最小化,對資料庫操作壓力會減小，這樣保證每張表數據量很小，操作速度會快，也可以在這里使用緩存
二 索引：
針對是否建立索引有著一定的分歧：
我覺得建立索引還是很有必要的。理由如下：
1）建立索引可以加快檢索速度，對於論壇讀和寫的比例相差很大，用戶體驗當然是讀多寫少，所以綜合考慮還是要用索引，而且是加在常用的讀關鍵字上。
2）索引之所以會降低更新的速度，是因為更新還包括對索引的更新，從更新帖子10萬左右，這句話是說，我們可能對發帖標題，發帖內容，回復標題，回復內容這4個欄位做更新。需要注意的是，這四個欄位並不是用來建立表連接的欄位，為了優化查詢速度我們不會在這四個欄位上建立索引，所以從這道題目出發，我們建立的索引不會影響更新帖子的性能。只要被索引的列（例如回復表的標題ID）不被頻繁更新,即使索引所在地行的其它列被頻繁update,索引也不會被更新從而產生性能消耗,一張表一天30萬次的索引更新,因它引起的性能消耗小到即使資料庫安裝在奔騰3單核CPU下都能輕松承擔下來。
3）對於更新的速度慢的問題，我們有解決的方法，你提交更新了後，前台可以讓程序返回一個正確結果，後台開個線程非同步慢慢跟新資料庫就是了，反正更新成功的前提就是假設資料庫連接永遠正確並處於可靠狀態。在資料庫和用戶之間建立一個緩沖區。(如，將更新的數據放到內存中，達到一定數量的時候再統一更新資料庫。假如以100條為例，一旦內存中達到100條數據量將這100條數據統一入庫。減少insert操作)

三 緩沖：
讀的時候的緩沖：緩存路由表
主題緩存表（這個取每個區的前面100條記錄），一般來說負載最大的就是主題的第一頁，所以緩存表是個小表。

另外使用hibernate，在資料庫上面加了一層緩存。
生成靜態頁，緩存最熱，最新的帖子。
對於經常更新的數據都設計成單獨表 ，這樣可以最大程度的利用hibernate緩存
緩存常用的數據和表，利用緩存來將經常被訪問的帖子留在內存中，為每條緩存的記錄添加一個訪問時間，如果長時間沒被訪問就從緩存中刪除掉，
避免內存過大，每次用戶看帖的時候，首先檢索緩存中時候有需要的帖子，沒有的話再訪問資料庫，然後將資料庫返回的帖子信息存儲到緩存中。

寫的時候的緩沖：資料庫和用戶之間建立緩存，將更新的數據放在內存中，非同步操作的。所有的寫貼操作 放到一個隊列然後批量執行插入資料庫操作。

預估計的緩沖：假如用戶第一次打開某標題，那將此標題的相關的前100條數據緩存到客戶斷。這樣避開對資料庫的直接查詢，減少資料庫壓力。
四 代碼優化
1盡量避免表的連接約束通過代碼來實現約束 例如用戶id的驗證在用戶登錄時驗證這樣就可以把帖子表的用戶id外鍵去掉這樣就成了單表操作、查詢 而連接可以通過觸發來實現這樣最多是查詢了3個表而不是連接中的笛卡爾笛卡爾積 回復表的查詢限定每次查詢的記錄數例如限定10條其它的通過點擊觸發來操作"注代碼優化容易出現bug 原因有些開發工具本身有優化"
五 資料庫性能調優
盡量用硬體來代替軟體優化 原則就是能用硬體的盡量用硬體 比如磁碟陣列 RAID0 有條件用RAID10 加大內存 .避免小表上建索引 對論壇來說數據帖子和回復不是很重要 可以定期刪除一些垃圾帖子 樓主說的幾百萬條記錄的論壇對現在的資料庫管理系統和計算機來說永不著刻意的優化,定期維護打包備份資料庫就可以了
提高速度的關鍵:
1.建立合理的索引並在查詢時充分利用;
2.避免使用關聯,這樣避免整表掃描;使用關聯不如多次使用主鍵查詢來的快;
3.一些處理的功能盡可能放到內存中來做,比如組織主題和回復;
4.海量緩存（使用靜態頁面也是個不錯的做法）
5 定期對表進行轉儲

⑸ 請簡要的敘述一下資料庫的主要設計過程

一、資料庫設計過程

資料庫技術是信息資源管理最有效的手段。

資料庫設計是指：對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。

資料庫設計的各階段：

A、需求分析階段：綜合各個用戶的應用需求(現實世界的需求)。

B、在概念設計階段：形成獨立於機器和各DBMS產品的概念模式(信息世界模型)，用E-R圖來描述。

C、在邏輯設計階段：將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式。然後根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖(VIEW)形成數據的外模式。

D、在物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。

1. 需求分析階段

需求收集和分析，結果得到數據字典描述的數據需求(和數據流圖描述的處理需求)。

需求分析的重點：調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。

需求分析的方法：調查組織機構情況、各部門的業務活動情況、協助用戶明確對新系統的各種要求、確定新系統的邊界。

常用的調查方法有： 跟班作業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄。

分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。自頂向下的結構化分析方法(Structured Analysis，簡稱SA方法)從最上層的系統組織機構入手，採用逐層分解的方式分析系統，並把每一層用數據流圖和數據字典描述。

數據流圖表達了數據和處理過程的關系。系統中的數據則藉助數據字典(Data Dictionary，簡稱DD)來描述。

2. 概念結構設計階段

通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。

概念模型用於信息世界的建模。概念模型不依賴於某一個DBMS支持的數據模型。概念模型可以轉換為計算機上某一DBMS支持的特定數據模型。

概念模型特點：

(1) 具有較強的語義表達能力，能夠方便、直接地表達應用中的各種語義知識。

(2) 應該簡單、清晰、易於用戶理解，是用戶與資料庫設計人員之間進行交流的語言。

概念模型設計的一種常用方法為IDEF1X方法，它就是把實體-聯系方法應用到語義數據模型中的一種語義模型化技術，用於建立系統信息模型。

作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

2.1 第零步——初始化工程

這個階段的任務是從目的描述和范圍描述開始，確定建模目標，開發建模計劃，組織建模隊伍，收集源材料，制定約束和規范。收集源材料是這階段的重點。通過調查和觀察結果，業務流程，原有系統的輸入輸出，各種報表，收集原始數據，形成了基本數據資料表。

2.2 第一步——定義實體

實體集成員都有一個共同的特徵和屬性集，可以從收集的源材料——基本數據資料表中直接或間接標識出大部分實體。根據源材料名字表中表示物的術語以及具有 「代碼」結尾的術語，如客戶代碼、代理商代碼、產品代碼等將其名詞部分代表的實體標識出來，從而初步找出潛在的實體，形成初步實體表。

2.3 第二步——定義聯系

IDEF1X模型中只允許二元聯系，n元聯系必須定義為n個二元聯系。根據實際的業務需求和規則，使用實體聯系矩陣來標識實體間的二元關系，然後根據實際情況確定出連接關系的勢、關系名和說明，確定關系類型，是標識關系、非標識關系(強制的或可選的)還是非確定關系、分類關系。如果子實體的每個實例都需要通過和父實體的關系來標識，則為標識關系，否則為非標識關系。非標識關系中，如果每個子實體的實例都與而且只與一個父實體關聯，則為強制的，否則為非強制的。如果父實體與子實體代表的是同一現實對象，那麼它們為分類關系。

2.4 第三步——定義碼

通過引入交叉實體除去上一階段產生的非確定關系，然後從非交叉實體和獨立實體開始標識侯選碼屬性，以便唯一識別每個實體的實例，再從侯選碼中確定主碼。為了確定主碼和關系的有效性，通過非空規則和非多值規則來保證，即一個實體實例的一個屬性不能是空值，也不能在同一個時刻有一個以上的值。找出誤認的確定關系，將實體進一步分解，最後構造出IDEF1X模型的鍵基視圖(KB圖)。

2.5 第四步——定義屬性

從源數據表中抽取說明性的名詞開發出屬性表，確定屬性的所有者。定義非主碼屬性，檢查屬性的非空及非多值規則。此外，還要檢查完全依賴函數規則和非傳遞依賴規則，保證一個非主碼屬性必須依賴於主碼、整個主碼、僅僅是主碼。以此得到了至少符合關系理論第三範式的改進的IDEF1X模型的全屬性視圖。

2.6 第五步——定義其他對象和規則

定義屬性的數據類型、長度、精度、非空、預設值、約束規則等。定義觸發器、存儲過程、視圖、角色、同義詞、序列等對象信息。

3. 邏輯結構設計階段

將概念結構轉換為某個DBMS所支持的數據模型(例如關系模型)，並對其進行優化。設計邏輯結構應該選擇最適於描述與表達相應概念結構的數據模型，然後選擇最合適的DBMS。

將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的聯系轉化為關系模式,這種轉換一般遵循如下原則：一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。

數據模型的優化，確定數據依賴，消除冗餘的聯系，確定各關系模式分別屬於第幾範式。確定是否要對它們進行合並或分解。一般來說將關系分解為3NF的標准，即：

表內的每一個值都只能被表達一次。

表內的每一行都應該被唯一的標識(有唯一鍵)。

表內不應該存儲依賴於其他鍵的非鍵信息。

作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

4. 資料庫物理設計階段

為邏輯數據模型選取一個最適合應用環境的物理結構(包括存儲結構和存取方法)。根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。

5. 資料庫實施階段

運用DBMS提供的數據語言(例如SQL)及其宿主語言(例如C)，根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。 資料庫實施主要包括以下工作：用DDL定義資料庫結構、組織數據入庫 、編制與調試應用程序、資料庫試運行 ，(Data Definition Language(DDL數據定義語言)用作開新數據表、設定欄位、刪除數據表、刪除欄位，管理所有有關資料庫結構的東西)

●Create (新增有關資料庫結構的東西，屬DDL)

●Drop (刪除有關資料庫結構的東西，屬DDL)

●Alter (更改結構，屬DDL)

6. 資料庫運行和維護階段

在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。內容包括：資料庫的轉儲和恢復、資料庫的安全性、完整性控制、資料庫性能的監督、分析和改進、資料庫的重組織和重構造。

7. 建模工具的使用

為加快資料庫設計速度，目前有很多資料庫輔助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。

ERwin主要用來建立資料庫的概念模型和物理模型。它能用圖形化的方式，描述出實體、聯系及實體的屬性。ERwin支持IDEF1X方法。通過使用 ERwin建模工具自動生成、更改和分析IDEF1X模型，不僅能得到優秀的業務功能和數據需求模型，而且可以實現從IDEF1X模型到資料庫物理設計的轉變。ERwin工具繪制的模型對應於邏輯模型和物理模型兩種。在邏輯模型中，IDEF1X工具箱可以方便地用圖形化的方式構建和繪制實體聯系及實體的屬性。在物理模型中，ERwin可以定義對應的表、列，並可針對各種資料庫管理系統自動轉換為適當的類型。

設計人員可根據需要選用相應的資料庫設計建模工具。例如需求分析完成之後，設計人員可以使用Erwin畫ER圖，將ER圖轉換為關系數據模型，生成資料庫結構;畫數據流圖，生成應用程序。

二、資料庫設計技巧

1. 設計資料庫之前(需求分析階段)

1) 理解客戶需求，包括用戶未來需求變化。

2) 了解企業業務類型，可以在開發階段節約大量的時間。

3) 重視輸入(要記錄的數據)、輸出(報表、查詢、視圖)。

4) 創建數據字典和ER 圖表

數據字典(Data Dictionary，簡稱DD)是各類數據描述的集合，是關於資料庫中數據的描述，即元數據，不是數據本身。(至少應該包含每個欄位的數據類型和在每個表內的主外鍵)。

數據項描述: 數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數據項的邏輯關系

數據結構描述: 數據結構名，含義說明，組成:[數據項或數據結構]

數據流描述: 數據流名，說明，數據流來源，數據流去向， 組成:[數據結構]，平均流量，高峰期流量

數據存儲描述: 數據存儲名，說明，編號，流入的數據流，流出的數據流，組成:[數據結構]，數據量，存取方式

處理過程描述: 處理過程名，說明，輸入:[數據流]，輸出:[數據流]，處理:[簡要說明]

ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。

5) 定義標準的對象命名規范

資料庫各種對象的命名必須規范。

作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

2. 表和欄位的設計(資料庫邏輯設計)

表設計原則

1) 標准化和規范化

數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form(3NF)通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。

2) 數據驅動

採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。

舉例，假如用戶界面要訪問外部數據源(文件、XML 文檔、其他資料庫等)，不妨把相應的連接和路徑信息存儲在用戶界面支持的表裡。如果用戶界面執行工作流之類的任務(發送郵件、列印信箋、修改記錄狀態等)，那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。

3) 考慮各種變化

在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。

4) 表名、報表名和查詢名的命名規范

(採用前綴命名)檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。你可以統一地命名這些資料庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區別。如果採用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對象(比如 tbl_Employees)。用 sp_company 標識存儲過程，用 udf_ (或者類似的標記)標識自定義編寫的函數。

欄位設計原則：

1) 每個表中都應該添加的3 個有用的欄位。

dRecordCreationDate，在SQL Server 下默認為GETDATE()

sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT USER

nRecordVersion，記錄的版本標記;有助於准確說明記錄中出現null 數據或者丟失數據的原因

時效性數據應包括「最近更新日期/時間」欄位。時間標記對查找數據問題的原因、按日期重新處理/重載數據和清除舊數據特別有用。

2) 對地址和電話採用多個欄位

描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。

3) 表內的列[欄位]的命名規則(採用前綴/後綴命名)、採用有意義的欄位名

對列[欄位]名應該採用標準的前綴和後綴。如鍵是數字類型：用 _N 後綴;字元類型：_C 後綴;日期類型：_D 後綴。再如，假如你的表裡有好多「money」欄位，你不妨給每個列[欄位]增加一個 _M 後綴。

作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

假設有兩個表：

Customer 和 Order。Customer 表的前綴是 cu_，所以該表內的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是 or_，所以子段名是：

or_order_id、or_cust_name_id、or_quantity 和 or_description 等。

這樣從資料庫中選出全部數據的 SQL 語句可以寫成如下所示：

Select * From Customer, Order Where cu_surname = "MYNAME" ;

and cu_name_id = or_cust_name_id and or_quantity = 1

在沒有這些前綴的情況下則寫成這個樣子(用別名來區分)：

Select * From Customer, Order Where Customer.surname = "MYNAME" ;

and Customer.name_id = Order.cust_name_id and Order.quantity = 1

第 1 個 SQL 語句沒少鍵入多少字元。但如果查詢涉及到 5 個表乃至更多的列[欄位]你就知道這個技巧多有用了。

5) 選擇數字類型和文本類型的長度應盡量充足

假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。

6) 增加刪除標記欄位

在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行;最好採用清除數據程序而且要仔細維護索引整體性。

7) 提防大小寫混用的對象名和特殊字元

採用全部大寫而且包含下劃符的名字具有更好的可讀性(CUSTOMER_DATA)，絕對不要在對象名的字元之間留空格。

8) 小心保留詞

要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突，比如，用 DESC 作為說明欄位名。後果可想而知!DESC 是 DESCENDING 縮寫後的保留詞。表裡的一個 SELECT * 語句倒是能用，但得到的卻是一大堆毫無用處的信息。

9) 保持欄位名和類型的一致性

在命名欄位並為其指定數據類型的時候一定要保證一致性。假如欄位在表1中叫做「agreement_number」，就別在表2里把名字改成 「ref1」。假如數據類型在表1里是整數，那在表2里可就別變成字元型了。當然在表1(ABC)有處鍵ID，則為了可讀性，在表2做關聯時可以命名為 ABC_ID。

10) 避免使用觸發器

觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。

作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

3. 選擇鍵和索引(資料庫邏輯設計)

參考：《SQL優化-索引》一文

4. 數據完整性設計(資料庫邏輯設計)

1) 完整性實現機制：

實體完整性：主鍵

參照完整性：

父表中刪除數據：級聯刪除;受限刪除;置空值

父表中插入數據：受限插入;遞歸插入

父表中更新數據：級聯更新;受限更新;置空值

DBMS對參照完整性可以有兩種方法實現：外鍵實現機制(約束規則)和觸發器實現機制用戶定義完整性：

NOT NULL;CHECK;觸發器

2) 用約束而非商務規則強制數據完整性

採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。不要依賴於商務層保證數據完整性;它不能保證表之間(外鍵) 的完整性所以不能強加於其他完整性規則之上。如果你在數據層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用用戶理解的語言通知用戶界面。

3) 強制指示完整性

在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。

4) 使用查找控制數據完整性

控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。

5) 採用視圖

為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。

6) 分布式數據系統

對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來 5 年或者 10 年的數據量。當你把數據傳送到其他站點的時候，最好在資料庫欄位中設置一些標記，在目的站點收到你的數據之後更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。

7) 關系

如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那麼你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。

8) 給數據保有和恢復制定計劃

考慮數據保存策略並包含在設計過程中，預先設計你的數據恢復過程。採用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來「更新查詢」供以後萬一數據丟失可以重新處理更新。

9) 用存儲過程讓系統做重活

提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。資料庫不只是一個存放數據的地方，它也是簡化編碼之地。

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

5. 其他設計技巧

1) 避免使用觸發器

觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。

2) 使用常用英語(或者其他任何語言)而不要使用編碼

在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。

3) 保存常用信息

讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復(對Access)、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。

4) 包含版本機制

在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。

5) 編制文檔

對所有的快捷方式、命名規范、限制和函數都要編制文檔。

採用給表、列、觸發器等加註釋的 資料庫工具。對開發、支持和跟蹤修改非常有用。

對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。

6) 測試、測試、反復測試

建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。

7) 檢查設計

在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。

三、資料庫命名規范

1. 實體(表)的命名

1) 表以名詞或名詞短語命名，確定表名是採用復數還是單數形式，此外給表的別名定義簡單規則(比方說，如果表名是一個單詞，別名就取單詞的前4 個字母;如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名;如果表的名字由3 個單片語成，從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成4 字母長的別名，其餘依次類推)

對工作用表來說，表名可以加上前綴WORK_ 後面附上採用該表的應用程序的名字。在命名過程當中，根據語義拼湊縮寫即可。注意：將欄位名稱會統一成大寫或者小寫中的一種，故中間加上下劃線。

作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

舉例：

定義的縮寫 Sales: Sal 銷售;

Order: Ord 訂單;

Detail: Dtl 明細;

則銷售訂單明細表命名為：Sal_Ord_Dtl;

2) 如果表或者是欄位的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞。

舉例：

定義的縮寫 Material Ma 物品;

物品表名為：Material, 而不是 Ma.

但是欄位物品編碼則是：Ma_ID;而不是Material_ID

3) 所有的存儲值列表的表前面加上前綴Z

目的是將這些值列表類排序在資料庫最後。

4) 所有的冗餘類的命名(主要是累計表)前面加上前綴X

冗餘類是為了提高資料庫效率，非規范化資料庫的時候加入的欄位或者表

5) 關聯類通過用下劃線連接兩個基本類之後，再加前綴R的方式命名,後面按照字母順序羅列兩個表名或者表名的縮寫。

關聯表用於保存多對多關系。

如果被關聯的表名大於10個字母，必須將原來的表名的進行縮寫。如果沒有其他原因，建議都使用縮寫。

舉例：表Object與自身存在多對多的關系,則保存多對多關系的表命名為：R_Object;

作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17

本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……

2. 屬性(列)的命名

1) 採用有意義的列名

表內的列要針對鍵採用一整套設計規則。每一個表都將有一個自動ID作為主健,邏輯上的主健作為第一組候選主健來定義;

A、如果是資料庫自動生成的編碼，統一命名為：ID

B、如果是自定義的邏輯上的編碼則用縮寫加「ID」的方法命名，即「XXXX_ID」

C、如果鍵是數字類型，你可以用_NO 作為後綴;

D、如果是字元類型則可以採用_CODE 後綴

E、對列名應該採用標準的前綴和後綴。

舉例：銷售訂單的編號欄位命名：Sal_Ord_ID;如果還存在一個資料庫生成的自動編號，則命名為：ID。

2) 所有的屬性加上有關類型的後綴

注意，如果還需要其它的後綴，都放在類型後綴之前。

注: 數據類型是文本的欄位，類型後綴TX可以不寫。有些類型比較明顯的欄位，可以不寫類型後綴。

3) 採用前綴命名

給每個表的列名都採用統一的前綴，那麼在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列名同某些資料庫聯系起來。

3. 視圖的命名

1) 視圖以V作為前綴，其他命名規則和表的命名類似;

2) 命名應盡量體現各視圖的功能。

4. 觸發器的命名(盡量不使用)

觸發器以TR作為前綴，觸發器名為相應的表名加上後綴，Insert觸發器加'_I'，Delete觸發器加'_D'，Update觸發器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。

5. 存儲過程名

存儲過程應以'UP_'開頭，和系統的存儲過程區分，後續部分主要以動賓形式構成，並用下劃線分割各個組成部分。如增加代理商的帳戶的存儲過程為'UP_Ins_Agent_Account'。

6. 變數名

變數名採用小寫，若屬於片語形式，用下劃線分隔每個單詞，如@my_err_no。

7. 命名中其他注意事項

1) 以上命名都不得超過30個字元的系統限制。變數名的長度限制為29(不包括標識字元@)。

2) 數據對象、變數的命名都採用英文字元，禁止使用中文命名。絕對不要在對象名的字元之間留空格。

3) 小心保留詞，要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突

4) 保持欄位名和類型的一致性，在命名欄位並為其指定數據類型的時候一定要保證一致性。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。

⑹ 試述資料庫完整的設計過程

資料庫設計的過程(六個階段)
1.需求分析階段
准確了解與分析用戶需求（包括數據與處理）
是整個設計過程的基礎，是最困難、最耗費時間的一步
2.概念結構設計階段
是整個資料庫設計的關鍵
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
3.邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型
對其進行優化
4.資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）
5.資料庫實施階段
運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果
建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行
6.資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改
設計特點:
在設計過程中把資料庫的設計和對資料庫中數據處理的設計緊密結合起來將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計

⑺ 濡備綍璁捐′竴涓浼樼鐨勬暟鎹搴

鏁版嵁搴撹捐(Database Design)鏄鎸囧逛簬涓涓緇欏畾鐨勫簲鐢ㄧ幆澧冿紝鏋勯犳渶浼樼殑鏁版嵁搴撴ā寮忥紝寤虹珛鏁版嵁搴撳強鍏跺簲鐢ㄧ郴緇燂紝浣誇箣鑳藉熸湁鏁堝湴瀛樺偍鏁版嵁錛屾弧瓚沖悇縐嶇敤鎴風殑搴旂敤闇奼傦紙淇℃伅瑕佹眰鍜屽勭悊瑕佹眰錛夈 鍦ㄦ暟鎹搴撻嗗煙鍐咃紝甯稿父鎶婁嬌鐢ㄦ暟鎹搴撶殑鍚勭被緋葷粺緇熺О涓烘暟鎹搴撴暟鎹搴撹捐(database design)鏄鎸囧逛簬涓涓緇欏畾鐨勫簲鐢ㄧ幆澧冿紝鏋勯犳渶浼樼殑鏁版嵁搴撴ā寮忥紝寤虹珛鏁版嵁搴撳強鍏跺簲鐢ㄧ郴緇燂紝浣誇箣鑳藉熸湁鏁堝湴瀛樺偍鏁版嵁錛屾弧瓚沖悇縐嶇敤鎴風殑搴旂敤闇奼傦紙淇℃伅瑕佹眰鍜屽勭悊瑕佹眰錛夈 鍦ㄦ暟鎹搴撻嗗煙鍐咃紝甯稿父鎶婁嬌鐢ㄦ暟鎹搴撶殑鍚勭被緋葷粺緇熺О涓烘暟鎹搴撳簲鐢ㄧ郴緇熴 涓銆佹暟鎹搴撳拰淇℃伅緋葷粺 (1)鏁版嵁搴撴槸淇℃伅緋葷粺鐨勬牳蹇冨拰鍩虹錛屾妸淇℃伅緋葷粺涓澶ч噺鐨勬暟鎹鎸変竴瀹氱殑妯″瀷緇勭粐璧鋒潵錛屾彁渚涘瓨鍌ㄣ佺淮鎶ゃ佹緔㈡暟鎹鐨 鍔熻兘錛屼嬌淇℃伅緋葷粺鍙浠ユ柟渚褲佸強鏃躲佸噯紜鍦頒粠鏁版嵁搴撲腑鑾峰緱鎵闇鐨勪俊鎮銆 (2)鏁版嵁搴撴槸淇℃伅緋葷粺鐨勫悇涓閮ㄥ垎鑳藉惁緔у瘑鍦扮粨鍚堝湪涓璧蜂互鍙婂備綍緇撳悎鐨勫叧閿鎵鍦ㄣ (3)鏁版嵁搴撹捐℃槸淇℃伅緋葷粺寮鍙戝拰寤鴻劇殑閲嶈佺粍鎴愰儴鍒嗐 (4)鏁版嵁搴撹捐′漢鍛樺簲璇ュ叿澶囩殑鎶鏈鍜岀煡璇嗭細 鏁版嵁搴撶殑鍩烘湰鐭ヨ瘑鍜屾暟鎹搴撹捐℃妧鏈 璁＄畻鏈虹戝︾殑鍩虹鐭ヨ瘑鍜岀▼搴忚捐＄殑鏂規硶鍜屾妧宸 杞浠跺伐紼嬬殑鍘熺悊鍜屾柟娉 搴旂敤棰嗗煙鐨勭煡璇 浜屻佹暟鎹搴撹捐＄殑鐗圭偣 鏁版嵁搴撳緩璁炬槸紜浠躲佽蔣浠跺拰騫蹭歡鐨勭粨鍚 涓夊垎鎶鏈錛屼竷鍒嗙＄悊錛屽嶮浜屽垎鍩虹鏁版嵁 鎶鏈涓庣＄悊鐨勭晫闈㈢О涔嬩負鈥滃共浠垛 鏁版嵁搴撹捐″簲璇ヤ笌搴旂敤緋葷粺璁捐＄浉緇撳悎 緇撴瀯錛堟暟鎹錛夎捐★細璁捐℃暟鎹搴撴嗘灦鎴栨暟鎹搴撶粨鏋 琛屼負錛堝勭悊錛夎捐★細璁捐″簲鐢ㄧ▼搴忋佷簨鍔″勭悊絳 緇撴瀯鍜岃屼負鍒嗙葷殑璁捐 浼犵粺鐨勮蔣浠跺伐紼嬪拷瑙嗗瑰簲鐢ㄤ腑鏁版嵁璇涔夌殑鍒嗘瀽鍜屾娊璞★紝鍙瑕佹湁鍙鑳藉氨灝介噺鎺ㄨ繜鏁版嵁緇撴瀯璁捐＄殑鍐崇瓥鏃╂湡鐨勬暟鎹搴撹捐¤嚧鍔涗簬鏁版嵁妯″瀷鍜屽緩妯℃柟娉曠爺絀訛紝蹇借嗕簡瀵硅屼負鐨勮捐 濡傚浘錛 涓夈佹暟鎹搴撹捐℃柟娉曠畝榪 鎵嬪伐璇曞噾娉 璁捐¤川閲忎笌璁捐′漢鍛樼殑緇忛獙鍜屾按騫蟲湁鐩存帴鍏崇郴 緙轟箯縐戝︾悊璁哄拰宸ョ▼鏂規硶鐨勬敮鎸侊紝宸ョ▼鐨勮川閲忛毦浠ヤ繚璇 鏁版嵁搴撹繍琛屼竴孌墊椂闂村悗甯稿父鍙堜笉鍚岀▼搴﹀湴鍙戠幇鍚勭嶉棶棰橈紝澧炲姞浜嗙淮鎶や唬浠 瑙勮寖璁捐℃硶 鎵嬪伐璁捐℃柟 鍩烘湰鎬濇兂 榪囩▼榪浠ｅ拰閫愭ユ眰綺 瑙勮寖璁捐℃硶(緇) 鍏稿瀷鏂規硶錛 (1)鏂板ゥ灝旇壇錛坣ew orleans錛夋柟娉曪細灝嗘暟鎹搴撹捐″垎涓哄洓涓闃舵 s.b.yao鏂規硶錛氬皢鏁版嵁搴撹捐″垎涓轟簲涓姝ラ i.r.palmer鏂規硶錛氭妸鏁版嵁搴撹捐″綋鎴愪竴姝ユ帴涓姝ョ殑榪囩▼ (2)璁＄畻鏈鴻緟鍔╄捐 oracle designer 2000 sybase powerdesigner 鍥涖佹暟鎹搴撹捐＄殑鍩烘湰姝ラ 鏁版嵁搴撹捐＄殑榪囩▼(鍏涓闃舵) 1.闇奼傚垎鏋愰樁孌 鍑嗙『浜嗚В涓庡垎鏋愮敤鎴烽渶奼傦紙鍖呮嫭鏁版嵁涓庡勭悊錛 鏄鏁翠釜璁捐¤繃紼嬬殑鍩虹錛屾槸鏈鍥伴毦銆佹渶鑰楄垂鏃墮棿鐨勪竴姝 2.姒傚康緇撴瀯璁捐￠樁孌 鏄鏁翠釜鏁版嵁搴撹捐＄殑鍏抽敭 閫氳繃瀵圭敤鎴烽渶奼傝繘琛岀患鍚堛佸綊綰充笌鎶借薄錛屽艦鎴愪竴涓鐙絝嬩簬鍏蜂綋dbms鐨勬傚康妯″瀷 3.閫昏緫緇撴瀯璁捐￠樁孌 灝嗘傚康緇撴瀯杞鎹涓烘煇涓猟bms鎵鏀鎸佺殑鏁版嵁妯″瀷 瀵瑰叾榪涜屼紭鍖 4.鏁版嵁搴撶墿鐞嗚捐￠樁孌 涓洪昏緫鏁版嵁妯″瀷閫夊彇涓涓鏈閫傚悎搴旂敤鐜澧冪殑鐗╃悊緇撴瀯錛堝寘鎷瀛樺偍緇撴瀯鍜屽瓨鍙栨柟娉曪級 5.鏁版嵁搴撳疄鏂介樁孌 榪愮敤dbms鎻愪緵鐨勬暟鎹璇璦銆佸伐鍏峰強瀹誇富璇璦錛屾牴鎹閫昏緫璁捐″拰鐗╃悊璁捐＄殑緇撴灉 寤虹珛鏁版嵁搴擄紝緙栧埗涓庤皟璇曞簲鐢ㄧ▼搴忥紝緇勭粐鏁版嵁鍏ュ簱錛屽苟榪涜岃瘯榪愯 6.鏁版嵁搴撹繍琛屽拰緇存姢闃舵 鏁版嵁搴撳簲鐢ㄧ郴緇熺粡榪囪瘯榪愯屽悗鍗沖彲鎶曞叆姝ｅ紡榪愯屻 鍦ㄦ暟鎹搴撶郴緇熻繍琛岃繃紼嬩腑蹇呴』涓嶆柇鍦板瑰叾榪涜岃瘎浠楓佽皟鏁翠笌淇鏀 璁捐＄壒鐐: 鍦ㄨ捐¤繃紼嬩腑鎶婃暟鎹搴撶殑璁捐″拰瀵規暟鎹搴撲腑鏁版嵁澶勭悊鐨勮捐＄揣瀵嗙粨鍚堣搗鏉ュ皢榪欎袱涓鏂歸潰鐨勯渶奼傚垎鏋愩佹娊璞°佽捐°佸疄鐜板湪鍚勪釜闃舵靛悓鏃惰繘琛岋紝鐩鎬簰鍙傜収錛岀浉浜掕ˉ鍏咃紝浠ュ畬鍠勪袱鏂歸潰鐨勮捐 璁捐¤繃紼嬪悇涓闃舵電殑璁捐℃弿榪幫細 濡傚浘錛 浜斻佹暟鎹搴撳悇綰фā寮忕殑褰㈡垚榪囩▼ 1.闇奼傚垎鏋愰樁孌碉細緇煎悎鍚勪釜鐢ㄦ埛鐨勫簲鐢ㄩ渶奼 2.姒傚康璁捐￠樁孌碉細褰㈡垚鐙絝嬩簬鏈哄櫒鐗圭偣錛岀嫭絝嬩簬鍚勪釜dbms浜у搧鐨勬傚康妯″紡(e-r鍥) 3.閫昏緫璁捐￠樁孌碉細棣栧厛灝唀-r鍥捐漿鎹㈡垚鍏蜂綋鐨勬暟鎹搴撲駭鍝佹敮鎸佺殑鏁版嵁妯″瀷錛屽傚叧緋繪ā鍨嬶紝褰㈡垚鏁版嵁搴撻昏緫妯″紡錛涚劧鍚庢牴鎹鐢ㄦ埛澶勭悊鐨勮佹眰銆佸畨鍏ㄦх殑鑰冭檻錛屽湪鍩烘湰琛ㄧ殑鍩虹涓婂啀寤虹珛蹇呰佺殑瑙嗗浘(view)錛屽艦鎴愭暟鎹鐨勫栨ā寮 4.鐗╃悊璁捐￠樁孌碉細鏍規嵁dbms鐗圭偣鍜屽勭悊鐨勯渶瑕侊紝榪涜岀墿鐞嗗瓨鍌ㄥ畨鎺掞紝寤虹珛緔㈠紩錛屽艦鎴愭暟鎹搴撳唴妯″紡 鍏銆佹暟鎹搴撹捐℃妧宸 1. 璁捐℃暟鎹搴撲箣鍓嶏紙闇奼傚垎鏋愰樁孌碉級 1) 鐞嗚В瀹㈡埛闇奼傦紝璇㈤棶鐢ㄦ埛濡備綍鐪嬪緟鏈鏉ラ渶奼傚彉鍖栥傝╁㈡埛瑙ｉ噴鍏墮渶奼傦紝鑰屼笖闅忕潃寮鍙戠殑緇х畫錛岃繕瑕佺粡甯歌㈤棶瀹㈡埛淇濊瘉鍏墮渶奼備粛鐒跺湪寮鍙戠殑鐩鐨勪箣涓銆 2) 浜嗚В浼佷笟涓氬姟鍙浠ュ湪浠ュ悗鐨勫紑鍙戦樁孌佃妭綰﹀ぇ閲忕殑鏃墮棿銆 3) 閲嶈嗚緭鍏ヨ緭鍑恆 鍦ㄥ畾涔夋暟鎹搴撹〃鍜屽瓧孌甸渶奼傦紙杈撳叆錛夋椂錛岄栧厛搴旀鏌ョ幇鏈夌殑鎴栬呭凡緇忚捐″嚭鐨勬姤琛ㄣ佹煡璇㈠拰瑙嗗浘錛堣緭鍑猴級浠ュ喅瀹氫負浜嗘敮鎸佽繖浜涜緭鍑哄摢浜涙槸蹇呰佺殑琛ㄥ拰瀛楁點 涓句緥錛氬亣濡傚㈡埛闇瑕佷竴涓鎶ヨ〃鎸夌収閭鏀跨紪鐮佹帓搴忋佸垎孌靛拰奼傚拰錛屼綘瑕佷繚璇佸叾涓鍖呮嫭浜嗗崟鐙鐨勯偖鏀跨紪鐮佸瓧孌佃屼笉瑕佹妸閭鏀跨紪鐮佺硡榪涘湴鍧瀛楁甸噷銆 4) 鍒涘緩鏁版嵁瀛楀吀鍜宔r 鍥捐〃 er 鍥捐〃鍜屾暟鎹瀛楀吀鍙浠ヨ╀換浣曚簡瑙ｆ暟鎹搴撶殑浜洪兘鏄庣『濡備綍浠庢暟鎹搴撲腑鑾峰緱鏁版嵁銆俥r鍥懼硅〃鏄庤〃涔嬮棿鍏崇郴寰堟湁鐢錛岃屾暟鎹瀛楀吀鍒欒存槑浜嗘瘡涓瀛楁電殑鐢ㄩ斾互鍙婁換浣曞彲鑳藉瓨鍦ㄧ殑鍒鍚嶃傚箂ql 琛ㄨ揪寮忕殑鏂囨。鍖栨潵璇磋繖鏄瀹屽叏蹇呰佺殑銆 5) 瀹氫箟鏍囧噯鐨勫硅薄鍛藉悕瑙勮寖 鏁版嵁搴撳悇縐嶅硅薄鐨勫懡鍚嶅繀欏昏勮寖銆 2. 琛ㄥ拰瀛楁電殑璁捐★紙鏁版嵁搴撻昏緫璁捐★級 琛ㄨ捐″師鍒 1) 鏍囧噯鍖栧拰瑙勮寖鍖 鏁版嵁鐨勬爣鍑嗗寲鏈夊姪浜庢秷闄ゆ暟鎹搴撲腑鐨勬暟鎹鍐椾綑銆傛爣鍑嗗寲鏈夊ソ鍑犵嶅艦寮忥紝浣唗hird normal form錛3nf錛夐氬父琚璁や負鍦ㄦц兘銆佹墿灞曟у拰鏁版嵁瀹屾暣鎬ф柟闈㈣揪鍒頒簡鏈濂藉鉤琛°傜畝鍗曟潵璇達紝閬靛畧3nf 鏍囧噯鐨勬暟鎹搴撶殑琛ㄨ捐″師鍒欐槸錛氣渙ne fact in one place鈥濆嵆鏌愪釜琛ㄥ彧鍖呮嫭鍏舵湰韜鍩烘湰鐨勫睘鎬э紝褰撲笉鏄瀹冧滑鏈韜鎵鍏鋒湁鐨勫睘鎬ф椂闇榪涜屽垎瑙ｃ傝〃涔嬮棿鐨勫叧緋婚氳繃澶栭敭鐩歌繛鎺ャ傚畠鍏鋒湁浠ヤ笅鐗圭偣錛氭湁涓緇勮〃涓撻棬瀛樻斁閫氳繃閿榪炴帴璧鋒潵鐨勫叧鑱旀暟鎹銆 涓句緥錛氭煇涓瀛樻斁瀹㈡埛鍙婂叾鏈夊叧瀹氬崟鐨3nf 鏁版嵁搴撳氨鍙鑳芥湁涓や釜琛錛歝ustomer 鍜宱rder銆俹rder 琛ㄤ笉鍖呭惈瀹氬崟鍏寵仈瀹㈡埛鐨勪換浣曚俊鎮錛屼絾琛ㄥ唴浼氬瓨鏀句竴涓閿鍊礆紝璇ラ敭鎸囧悜customer 琛ㄩ噷鍖呭惈璇ュ㈡埛淇℃伅鐨勯偅涓琛屻 浜嬪疄涓婏紝涓轟簡鏁堢巼鐨勭紭鏁咃紝瀵硅〃涓嶈繘琛屾爣鍑嗗寲鏈夋椂涔熸槸蹇呰佺殑銆 2) 鏁版嵁椹卞姩 閲囩敤鏁版嵁椹卞姩鑰岄潪紜緙栫爜鐨勬柟寮忥紝璁稿氱瓥鐣ュ彉鏇村拰緇存姢閮戒細鏂逛究寰楀氾紝澶уぇ澧炲己緋葷粺鐨勭伒媧繪у拰鎵╁睍鎬с 涓句緥錛屽亣濡傜敤鎴風晫闈㈣佽塊棶澶栭儴鏁版嵁婧愶紙鏂囦歡銆亁ml 鏂囨。銆佸叾浠栨暟鎹搴撶瓑錛夛紝涓嶅Θ鎶婄浉搴旂殑榪炴帴鍜岃礬寰勪俊鎮瀛樺偍鍦ㄧ敤鎴風晫闈㈡敮鎸佽〃閲屻傝繕鏈夛紝濡傛灉鐢ㄦ埛鐣岄潰鎵ц屽伐浣滄祦涔嬬被鐨勪換鍔★紙鍙戦侀偖浠躲佹墦鍗頒俊絎恆佷慨鏀硅板綍鐘舵佺瓑錛夛紝閭ｄ箞浜х敓宸ヤ綔嫻佺殑鏁版嵁涔熷彲浠ュ瓨鏀懼湪鏁版嵁搴撻噷銆傝掕壊鏉冮檺綆＄悊涔熷彲浠ラ氳繃鏁版嵁椹卞姩鏉ュ畬鎴愩備簨瀹炰笂錛屽傛灉榪囩▼鏄鏁版嵁椹卞姩鐨勶紝浣犲氨鍙浠ユ妸鐩稿綋澶х殑璐ｄ換鎺ㄧ粰鐢ㄦ埛錛岀敱鐢ㄦ埛鏉ョ淮鎶よ嚜宸辯殑宸ヤ綔嫻佽繃紼嬨 3) 鑰冭檻鍚勭嶅彉鍖 鍦ㄨ捐℃暟鎹搴撶殑鏃跺欒冭檻鍒板摢浜涙暟鎹瀛楁靛皢鏉ュ彲鑳戒細鍙戠敓鍙樻洿銆 涓句緥錛屽撴皬灝辨槸濡傛わ紙娉ㄦ剰鏄瑗挎柟浜虹殑濮撴皬錛屾瘮濡傚コ鎬х粨濠氬悗浠庡か濮撶瓑錛夈傛墍浠ワ紝鍦ㄥ緩絝嬬郴緇熷瓨鍌ㄥ㈡埛淇℃伅鏃訛紝鍦ㄥ崟鐙鐨勪竴涓鏁版嵁琛ㄩ噷瀛樺偍濮撴皬瀛楁碉紝鑰屼笖榪橀檮鍔犺搗濮嬫棩鍜岀粓姝㈡棩絳夊瓧孌碉紝榪欐牱灝卞彲浠ヨ窡韙榪欎竴鏁版嵁鏉＄洰鐨勫彉鍖栥 瀛楁佃捐″師鍒 4) 姣忎釜琛ㄤ腑閮藉簲璇ユ坊鍔犵殑3 涓鏈夌敤鐨勫瓧孌 drecordcreationdate錛屽湪vb 涓嬮粯璁ゆ槸now()錛岃屽湪sql server ? 涓嬮粯璁や負getdate() srecordcreator錛屽湪sql server 涓嬮粯璁や負not null default ? user nrecordversion錛岃板綍鐨勭増鏈鏍囪幫紱鏈夊姪浜庡噯紜璇存槑璁板綍涓鍑虹幇null 鏁版嵁鎴栬呬涪澶辨暟鎹鐨勫師鍥 ? 5) 瀵瑰湴鍧鍜岀數璇濋噰鐢ㄥ氫釜瀛楁 鎻忚堪琛楅亾鍦板潃灝辯煭鐭涓琛岃板綍鏄涓嶅熺殑銆俛ddress_line1銆乤ddress_line2 鍜宎ddress_line3 鍙浠ユ彁渚涙洿澶х殑鐏墊椿鎬с傝繕鏈夛紝鐢佃瘽鍙風爜鍜岄偖浠跺湴鍧鏈濂芥嫢鏈夎嚜宸辯殑鏁版嵁琛錛屽叾闂村叿鏈夎嚜韜鐨勭被鍨嬪拰鏍囪扮被鍒銆 6) 浣跨敤瑙掕壊瀹炰綋瀹氫箟灞炰簬鏌愮被鍒鐨勫垪 鍦ㄩ渶瑕佸瑰睘浜庣壒瀹氱被鍒鎴栬呭叿鏈夌壒瀹氳掕壊鐨勪簨鐗╁仛瀹氫箟鏃訛紝鍙浠ョ敤瑙掕壊瀹炰綋鏉ュ壋寤虹壒瀹氱殑鏃墮棿鍏寵仈鍏崇郴錛屼粠鑰屽彲浠ュ疄鐜拌嚜鎴戞枃妗ｅ寲銆 涓句緥錛氱敤person 瀹炰綋鍜宲erson_type 瀹炰綋鏉ユ弿榪頒漢鍛樸傛瘮鏂硅達紝褰搄ohn smith, engineer 鎻愬崌涓簀ohn smith, director 涔冭嚦鏈鍚庣埇鍒癹ohn smith, cio 鐨勯珮浣嶏紝鑰屾墍鏈変綘瑕佸仛鐨勪笉榪囨槸鏀瑰彉涓や釜琛╬erson 鍜宲erson_type 涔嬮棿鍏崇郴鐨勯敭鍊礆紝鍚屾椂澧炲姞涓涓鏃ユ湡/鏃墮棿瀛楁墊潵鐭ラ亾鍙樺寲鏄浣曟椂鍙戠敓鐨勩傝繖鏍鳳紝浣犵殑person_type 琛ㄥ氨鍖呭惈浜嗘墍鏈塸erson 鐨勫彲鑳界被鍨嬶紝姣斿俛ssociate銆乪ngineer銆乨irector銆乧io 鎴栬卌eo 絳夈傝繕鏈変釜鏇誇唬鍔炴硶灝辨槸鏀瑰彉person 璁板綍鏉ュ弽鏄犳柊澶磋旂殑鍙樺寲錛屼笉榪囪繖鏍蜂竴鏉ュ湪鏃墮棿涓婃棤娉曡窡韙涓浜烘墍澶勪綅緗鐨勫叿浣撴椂闂淬 7) 閫夋嫨鏁板瓧綾誨瀷鍜屾枃鏈綾誨瀷灝介噺鍏呰凍 鍦╯ql 涓浣跨敤smallint 鍜宼inyint 綾誨瀷瑕佺壒鍒灝忓績銆傛瘮濡傦紝鍋囧傛兂鐪嬬湅鏈堥攢鍞鎬婚濓紝鎬婚濆瓧孌電被鍨嬫槸smallint錛岄偅涔堬紝濡傛灉鎬婚濊秴榪囦簡$32,767 灝變笉鑳借繘琛岃＄畻鎿嶄綔浜嗐 鑰宨d 綾誨瀷鐨勬枃鏈瀛楁碉紝姣斿傚㈡埛id 鎴栧畾鍗曞彿絳夌瓑閮藉簲璇ヨ劇疆寰楁瘮涓鑸鎯寵薄鏇村ぇ銆傚亣璁懼㈡埛id 涓10 浣嶆暟闀褲傞偅浣犲簲璇ユ妸鏁版嵁搴撹〃瀛楁電殑闀垮害璁句負12 鎴栬13 涓瀛楃﹂暱銆備絾榪欓濆栧崰鎹鐨勭┖闂村嵈鏃犻渶灝嗘潵閲嶆瀯鏁翠釜鏁版嵁搴撳氨鍙浠ュ疄鐜版暟鎹搴撹勬ā鐨勫為暱浜嗐 8) 澧炲姞鍒犻櫎鏍囪板瓧孌 鍦ㄨ〃涓鍖呭惈涓涓鈥滃垹闄ゆ爣璁扳濆瓧孌碉紝榪欐牱灝卞彲浠ユ妸琛屾爣璁頒負鍒犻櫎銆傚湪鍏崇郴鏁版嵁搴撻噷涓嶈佸崟鐙鍒犻櫎鏌愪竴琛岋紱鏈濂介噰鐢ㄦ竻闄ゆ暟鎹紼嬪簭鑰屼笖瑕佷粩緇嗙淮鎶ょ儲寮曟暣浣撴с 3. 閫夋嫨閿鍜岀儲寮曪紙鏁版嵁搴撻昏緫璁捐★級 閿閫夋嫨鍘熷垯錛 1) 閿璁捐4 鍘熷垯 涓哄叧鑱斿瓧孌靛壋寤哄栭敭銆 ? 鎵鏈夌殑閿閮藉繀欏誨敮涓銆 ? 閬垮厤浣跨敤澶嶅悎閿銆 ? 澶栭敭鎬繪槸鍏寵仈鍞涓鐨勯敭瀛楁點 ? 2) 浣跨敤緋葷粺鐢熸垚鐨勪富閿 璁捐℃暟鎹搴撶殑鏃跺欓噰鐢ㄧ郴緇熺敓鎴愮殑閿浣滀負涓婚敭錛岄偅涔堝疄闄呮帶鍒朵簡鏁版嵁搴撶殑緔㈠紩瀹屾暣鎬с傝繖鏍鳳紝鏁版嵁搴撳拰闈炰漢宸ユ満鍒跺氨鏈夋晥鍦版帶鍒朵簡瀵瑰瓨鍌ㄦ暟鎹涓姣忎竴琛岀殑璁塊棶銆傞噰鐢ㄧ郴緇熺敓鎴愰敭浣滀負涓婚敭榪樻湁涓涓浼樼偣錛氬綋鎷ユ湁涓鑷寸殑閿緇撴瀯鏃訛紝鎵懼埌閫昏緫緙洪櫡寰堝規槗銆 3) 涓嶈佺敤鐢ㄦ埛鐨勯敭(涓嶈╀富閿鍏鋒湁鍙鏇存柊鎬) 鍦ㄧ『瀹氶噰鐢ㄤ粈涔堝瓧孌典綔涓鴻〃鐨勯敭鐨勬椂鍊欙紝鍙涓瀹氳佸皬蹇冪敤鎴峰皢瑕佺紪杈戠殑瀛楁點傞氬父鐨勬儏鍐典笅涓嶈侀夋嫨鐢ㄦ埛鍙緙栬緫鐨勫瓧孌典綔涓洪敭銆 4) 鍙閫夐敭鏈夋椂鍙鍋氫富閿 鎶婂彲閫夐敭榪涗竴姝ョ敤鍋氫富閿錛屽彲浠ユ嫢鏈夊緩絝嬪己澶х儲寮曠殑鑳藉姏銆 緔㈠紩浣跨敤鍘熷垯錛 緔㈠紩鏄浠庢暟鎹搴撲腑鑾峰彇鏁版嵁鐨勬渶楂樻晥鏂瑰紡涔嬩竴銆95%鐨勬暟鎹搴撴ц兘闂棰橀兘鍙浠ラ噰鐢ㄧ儲寮曟妧鏈寰楀埌瑙ｅ喅銆 1) 閫昏緫涓婚敭浣跨敤鍞涓鐨勬垚緇勭儲寮曪紝瀵圭郴緇熼敭錛堜綔涓哄瓨鍌ㄨ繃紼嬶級閲囩敤鍞涓鐨勯潪鎴愮粍緔㈠紩錛屽逛換浣曞栭敭鍒楅噰鐢ㄩ潪鎴愮粍緔㈠紩銆傝冭檻鏁版嵁搴撶殑絀洪棿鏈夊氬ぇ錛岃〃濡備綍榪涜岃塊棶錛岃繕鏈夎繖浜涜塊棶鏄鍚︿富瑕佺敤浣滆誨啓銆 2) 澶у氭暟鏁版嵁搴撻兘緔㈠紩鑷鍔ㄥ壋寤虹殑涓婚敭瀛楁碉紝浣嗘槸鍙鍒蹇樹簡緔㈠紩澶栭敭錛屽畠浠涔熸槸緇忓父浣跨敤鐨勯敭錛屾瘮濡傝繍琛屾煡璇㈡樉紺轟富琛ㄥ拰鎵鏈夊叧鑱旇〃鐨勬煇鏉¤板綍灝辯敤寰椾笂銆 3) 涓嶈佺儲寮昺emo/note 瀛楁碉紝涓嶈佺儲寮曞ぇ鍨嬪瓧孌碉紙鏈夊緢澶氬瓧絎︼級錛岃繖鏍蜂綔浼氳╃儲寮曞崰鐢ㄥお澶氱殑瀛樺偍絀洪棿銆 4) 涓嶈佺儲寮曞父鐢ㄧ殑灝忓瀷琛 涓嶈佷負灝忓瀷鏁版嵁琛ㄨ劇疆浠諱綍閿錛屽亣濡傚畠浠緇忓父鏈夋彃鍏ュ拰鍒犻櫎鎿嶄綔灝辨洿鍒榪欐牱浣滀簡銆傚硅繖浜涙彃鍏ュ拰鍒犻櫎鎿嶄綔鐨勭儲寮曠淮鎶ゅ彲鑳芥瘮鎵鎻忚〃絀洪棿娑堣楁洿澶氱殑鏃墮棿銆 4. 鏁版嵁瀹屾暣鎬ц捐★紙鏁版嵁搴撻昏緫璁捐★級 1) 瀹屾暣鎬у疄鐜版満鍒訛細 瀹炰綋瀹屾暣鎬э細涓婚敭 鍙傜収瀹屾暣鎬э細 鐖惰〃涓鍒犻櫎鏁版嵁錛氱駭鑱斿垹闄わ紱鍙楅檺鍒犻櫎錛涚疆絀哄 鐖惰〃涓鎻掑叆鏁版嵁錛氬彈闄愭彃鍏ワ紱閫掑綊鎻掑叆 鐖惰〃涓鏇存柊鏁版嵁錛氱駭鑱旀洿鏂幫紱鍙楅檺鏇存柊錛涚疆絀哄 dbms瀵瑰弬鐓у畬鏁存у彲浠ユ湁涓ょ嶆柟娉曞疄鐜幫細澶栭敭瀹炵幇鏈哄埗錛堢害鏉熻勫垯錛夊拰瑙﹀彂鍣ㄥ疄鐜版満鍒 鐢ㄦ埛瀹氫箟瀹屾暣鎬э細 not null錛沜heck錛涜Е鍙戝櫒 2) 鐢ㄧ害鏉熻岄潪鍟嗗姟瑙勫垯寮哄埗鏁版嵁瀹屾暣鎬 閲囩敤鏁版嵁搴撶郴緇熷疄鐜版暟鎹鐨勫畬鏁存с傝繖涓嶄絾鍖呮嫭閫氳繃鏍囧噯鍖栧疄鐜扮殑瀹屾暣鎬ц屼笖榪樺寘鎷鏁版嵁鐨勫姛鑳芥с傚湪鍐欐暟鎹鐨勬椂鍊欒繕鍙浠ュ炲姞瑙﹀彂鍣ㄦ潵淇濊瘉鏁版嵁鐨勬ｇ『鎬с備笉瑕佷緷璧栦簬鍟嗗姟灞備繚璇佹暟鎹瀹屾暣鎬э紱瀹冧笉鑳戒繚璇佽〃涔嬮棿錛堝栭敭錛夌殑瀹屾暣鎬ф墍浠ヤ笉鑳藉己鍔犱簬鍏朵粬瀹屾暣鎬ц勫垯涔嬩笂銆 3) 寮哄埗鎸囩ず瀹屾暣鎬 鍦ㄦ湁瀹蟲暟鎹榪涘叆鏁版嵁搴撲箣鍓嶅皢鍏跺墧闄ゃ傛縺媧繪暟鎹搴撶郴緇熺殑鎸囩ず瀹屾暣鎬х壒鎬с傝繖鏍峰彲浠ヤ繚鎸佹暟鎹鐨勬竻媧佽岃兘榪浣垮紑鍙戜漢鍛樻姇鍏ユ洿澶氱殑鏃墮棿澶勭悊閿欒鏉′歡銆 4) 浣跨敤鏌ユ壘鎺у埗鏁版嵁瀹屾暣鎬 鎺у埗鏁版嵁瀹屾暣鎬х殑鏈浣蟲柟寮忓氨鏄闄愬埗鐢ㄦ埛鐨勯夋嫨銆傚彧瑕佹湁鍙鑳介兘搴旇ユ彁渚涚粰鐢ㄦ埛涓涓娓呮櫚鐨勪環鍊煎垪琛ㄤ緵鍏墮夋嫨銆傝繖鏍峰皢鍑忓皯閿鍏ヤ唬鐮佺殑閿欒鍜岃瑙ｅ悓鏃舵彁渚涙暟鎹鐨勪竴鑷存с傛煇浜涘叕鍏辨暟鎹鐗瑰埆閫傚悎鏌ユ壘錛氬浗瀹朵唬鐮併佺姸鎬佷唬鐮佺瓑銆 5) 閲囩敤瑙嗗浘 涓轟簡鍦ㄦ暟鎹搴撳拰搴旂敤紼嬪簭浠ｇ爜涔嬮棿鎻愪緵鍙︿竴灞傛娊璞★紝鍙浠ヤ負搴旂敤紼嬪簭寤虹珛涓撻棬鐨勮嗗浘鑰屼笉蹇呴潪瑕佸簲鐢ㄧ▼搴忕洿鎺ヨ塊棶鏁版嵁琛ㄣ傝繖鏍峰仛榪樼瓑浜庡湪澶勭悊鏁版嵁搴撳彉鏇存椂緇欎綘鎻愪緵浜嗘洿澶氱殑鑷鐢便 5. 鍏朵粬璁捐℃妧宸 1) 閬垮厤浣跨敤瑙﹀彂鍣 瑙﹀彂鍣ㄧ殑鍔熻兘閫氬父鍙浠ョ敤鍏朵粬鏂瑰紡瀹炵幇銆傚湪璋冭瘯紼嬪簭鏃惰Е鍙戝櫒鍙鑳芥垚涓哄共鎵般傚亣濡備綘紜瀹為渶瑕侀噰鐢ㄨЕ鍙戝櫒錛屼綘鏈濂介泦涓瀵瑰畠鏂囨。鍖栥 2) 浣跨敤甯哥敤鑻辮錛堟垨鑰呭叾浠栦換浣曡璦錛夎屼笉瑕佷嬌鐢ㄧ紪鐮 鍦ㄥ壋寤轟笅鎷夎彍鍗曘佸垪琛ㄣ佹姤琛ㄦ椂鏈濂芥寜鐓ц嫳璇鍚嶆帓搴忋傚亣濡傞渶瑕佺紪鐮侊紝鍙浠ュ湪緙栫爜鏃侀檮涓婄敤鎴風煡閬撶殑鑻辮銆 3) 淇濆瓨甯哥敤淇℃伅 璁╀竴涓琛ㄤ笓闂ㄥ瓨鏀句竴鑸鏁版嵁搴撲俊鎮闈炲父鏈夌敤銆傚湪榪欎釜琛ㄩ噷瀛樻斁鏁版嵁搴撳綋鍓嶇増鏈銆佹渶榪戞鏌/淇澶嶏紙瀵筧ccess錛夈佸叧鑱旇捐℃枃妗ｇ殑鍚嶇О銆佸㈡埛絳変俊鎮銆傝繖鏍峰彲浠ュ疄鐜頒竴縐嶇畝鍗曟満鍒惰窡韙鏁版嵁搴擄紝褰撳㈡埛鎶辨ㄤ粬浠鐨勬暟鎹搴撴病鏈夎揪鍒板笇鏈涚殑瑕佹眰鑰屼笌浣犺仈緋繪椂錛岃繖鏍峰仛瀵歸潪瀹㈡埛鏈/鏈嶅姟鍣ㄧ幆澧冪壒鍒鏈夌敤銆 4) 鍖呭惈鐗堟湰鏈哄埗 鍦ㄦ暟鎹搴撲腑寮曞叆鐗堟湰鎺у埗鏈哄埗鏉ョ『瀹氫嬌鐢ㄤ腑鐨勬暟鎹搴撶殑鐗堟湰銆傛椂闂翠竴闀匡紝鐢ㄦ埛鐨勯渶奼傛繪槸浼氭敼鍙樼殑銆傛渶緇堝彲鑳戒細瑕佹眰淇鏀規暟鎹搴撶粨鏋勩傛妸鐗堟湰淇℃伅鐩存帴瀛樻斁鍒版暟鎹搴撲腑鏇翠負鏂逛究銆 5) 緙栧埗鏂囨。 瀵規墍鏈夌殑蹇鎹鋒柟寮忋佸懡鍚嶈勮寖銆侀檺鍒跺拰鍑芥暟閮借佺紪鍒舵枃妗ｃ 閲囩敤緇欒〃銆佸垪銆佽Е鍙戝櫒絳夊姞娉ㄩ噴鐨勬暟鎹搴撳伐鍏楓傚瑰紑鍙戙佹敮鎸佸拰璺熻釜淇鏀歸潪甯告湁鐢ㄣ 瀵規暟鎹搴撴枃妗ｅ寲錛屾垨鑰呭湪鏁版嵁搴撹嚜韜鐨勫唴閮ㄦ垨鑰呭崟鐙寤虹珛鏂囨。銆傝繖鏍鳳紝褰撹繃浜嗕竴騫村氭椂闂村悗鍐嶅洖榪囧ご鏉ュ仛絎2 涓鐗堟湰錛岀姱閿欑殑鏈轟細灝嗗ぇ澶у噺灝戙 6) 嫻嬭瘯銆佹祴璇曘佸弽澶嶆祴璇 寤虹珛鎴栬呬慨璁㈡暟鎹搴撲箣鍚庯紝蹇呴』鐢ㄧ敤鎴鋒柊杈撳叆鐨勬暟鎹嫻嬭瘯鏁版嵁瀛楁點傛渶閲嶈佺殑鏄錛岃╃敤鎴瘋繘琛屾祴璇曞苟涓斿悓鐢ㄦ埛涓閬撲繚璇侀夋嫨鐨勬暟鎹綾誨瀷婊¤凍鍟嗕笟瑕佹眰銆傛祴璇曢渶瑕佸湪鎶婃柊鏁版嵁搴撴姇鍏ュ疄闄呮湇鍔′箣鍓嶅畬鎴愩 7) 媯鏌ヨ捐 鍦ㄥ紑鍙戞湡闂存鏌ユ暟鎹搴撹捐＄殑甯哥敤鎶鏈鏄閫氳繃鍏舵墍鏀鎸佺殑搴旂敤紼嬪簭鍘熷瀷媯鏌ユ暟鎹搴撱傛崲鍙ヨ瘽璇達紝閽堝規瘡涓縐嶆渶緇堣〃杈炬暟鎹鐨勫師鍨嬪簲鐢錛屼繚璇佷綘媯鏌ヤ簡鏁版嵁妯″瀷騫朵笖鏌ョ湅濡備綍鍙栧嚭鏁版嵁銆