1、建模工具：推薦使用powerdesigner（簡稱pd）。建議所有的設計工作都在pd裡面進行，然後通過pd直
接連到某個資料庫的功能，直接執行pd生成的指令碼。建議不要人為的在生成的具體資料庫中做結構上的二
次修改，否則可能忽略掉在pd中做相應的修改，導致以後檢視時出現某些表之間關係的不一致（據筆者經
驗，表之間關係和實際資料庫表關係的不一致在這種情況下顯得相當嚴重）
2、表名的命名約定：建議一律用小寫（oracle除外，因為oracle本身只支援大寫），表名每個單詞間用
統一的分隔符（建議用下劃線）分隔。列名等其它物件的命名建議按照這種方式定義。這樣做的好處，不
僅在閱讀上方便，而且在其它工作，比如根據表名、列名生成物件以及物件的屬性等方面，能夠方便的定
義出相應的針對表名等的處理函式。
3、字元型別選擇：字元型字段的型別，一般用varchar型，如果涉及中文的建議使用unicode編碼的
nvarchar。相應的對於大資料型別的有text和ntext（sql server）。
4、字元型別長度選擇：這個問題是筆者寫這篇文章的主要驅動點。在筆者參與的資料庫設計，以及從一
些有關資料庫設計方面的書中，筆者未曾看到過這樣的建議。也許這問題本身是相當的微不足道，但經過
筆者多次的親身體驗，還是覺得這個問題不可不提。原因主要有：大部分專案資料庫設計不是由乙個人設
計的，不同的人對字元型的長度定義都是憑當時的直覺的，這樣必然導致不同的人設計出來的表結構基本
上是不同的（即使是同一張表，但由不同的人設計）。這本來問題不大，但假如第乙個人設計了父表的某
個具有關聯性質的字元型字段用varchar(20)（憑直覺），而第二個人在設計子表時對關聯於父表的字元
型字段用varcahr(30)（甚至nvarchar(30)），這樣的結果也許結構本身不會報錯，但對於日後的查閱是
相當不便的。故筆者建議對字元型的字段以階梯型來定義其長度，筆者比較喜歡用這樣的階梯型：10、50
、100、500、1000、2000、4000、5000、8000等。如此一來，表中的字元型字段的長度即便對於後來的設
計人員，也是可預知的
待續
我對個人使用過的資料庫的一點個人體會
截至今天尚在使用的資料庫如下 2000年，開始使用mysql 2001年，開始使用sql server 2003年，開始使用oracle 目前最常用的，還是mysql和sql server.以前做過的專案中，oracle最多，因為公司購買了正版的資料庫和小型機。個人觀點 mysql 免費的，不需要別...
關於資料庫表設計的一點體會
以乙個實際工作為例，在乙個金融系統中，從業務上看有投資人和借款人這兩類使用者，但從使用者類別上看有企業使用者和個人使用者，請問建表時如何做比較好。方式一 user表 user person表 user enterprise表 方式二 user表 user investor 投資人表 user bor...
基於UML的需求分析和系統設計個人體會
閱讀了文章之後，對使用uml進行系統的需求分析和設計有了乙個基礎的理解。在此做一下整理。1.專案開始階段 專案開始階段的初期訪談需要抓住以下幾個重點 必要的業務流程 在摸索業務流程時，初期應該盡可能只捕捉就 必要的 業務流程，在該業務流程中，盡量避免對細節的研究。專案的技術限制 包括使用的技術以及其...