【正文】 Microsoft Visual FoxPro 設計技巧對復雜的 Microsoft Visual FoxPro 數(shù)據(jù)庫應用程序而言，可以把所有的主表放在一個數(shù)據(jù)庫容器文件里，然后增加其他數(shù)據(jù)庫表文件和裝載同原有數(shù)據(jù)庫有關的特殊文件。 保存常用信息讓一個表專門存放一般數(shù)據(jù)庫信息非常有用?；蛘吣憧赡芟Ｍ芷谛缘念A排，在輸入新數(shù)據(jù)同時隨著你的進展對每一部分細節(jié)化。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。 采用視圖為了在你的數(shù)據(jù)庫和你的應用程序代碼之間提供另一層抽象，你可以為你的應用程序建立專門的視圖而不必非要應用程序直接訪問數(shù)據(jù)表。在目的站點收到你的數(shù)據(jù)之后更新你的標記。如果你在數(shù)據(jù)層確實采用了約束，你要保證有辦法把更新不能通過約束檢查的原因采用用戶理解的語言通知用戶界面。我的看法是，假如你有可選鍵，比如國家表內的 state_code，你不要在現(xiàn)有不能變動的唯一鍵上創(chuàng)建后續(xù)的鍵。如果索引完整性規(guī)則施加到表一級，那么在不編寫大量代碼和附加刪除記錄的情況下幾乎不可能改變某一條記錄的鍵和數(shù)據(jù)庫內所有關聯(lián)的記錄。還有，鍵的糾正可能會迫使你突破你的數(shù)據(jù)和商業(yè)/用戶界面層之間的隔離。而且人們也都知道這是非法的，但他們已經習慣了。大多數(shù)數(shù)據(jù)庫都索引自動創(chuàng)建的主鍵字段，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯(lián)表的某條記錄就用得上。* 所有的鍵都必須唯一。這樣，數(shù)據(jù)庫和非人工機制就有效地控制了對存儲數(shù)據(jù)中每一行的訪問。我發(fā)現(xiàn)有一個指示計劃相當關鍵——當我想創(chuàng)建系統(tǒng)類型查找時為什么要采用號碼作為主索引字段呢？我可以用傳真號碼進行檢索，但是它幾乎就象系統(tǒng)類型一樣對我來說并不重要。and cu_name_id = or_cust_name_id and or_quantity = 1在沒有這些前綴的情況下則寫成這個樣子（用別名來區(qū)分）：Select * From Customer, Order Where = MYNAME 。但這額外占據(jù)的空間卻無需將來重構整個數(shù)據(jù)庫就可以實現(xiàn)數(shù)據(jù)庫規(guī)模的增長了。無論如何你都要實現(xiàn)這一要求。記住，你干完自己的活了，其他人還要用你的數(shù)據(jù)庫呢。我不喜歡采用這種大小寫混用的對象命名方法，結果還不得不手工修改名字。 使用多個名稱字段我覺得很吃驚，許多人在數(shù)據(jù)庫里就給 name 留一個字段。 用戶來自世界各地在設計用到網絡或者具有其他國際特性的數(shù)據(jù)庫時，一定要記住大多數(shù)國家都有不同的字段格式，比如郵政編碼等，有些國家，比如新西蘭就沒有郵政編碼一說。還有個替代辦法就是改變 PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。 Microsoft Visual FoxPro 報表技巧如果你正在使用 Microsoft Visual FoxPro，你可以用對用戶友好的字段名來代替編號的名稱：比如用 Customer Name 代替 txtCNaM。Order 表不包含定單關聯(lián)客戶的任何信息，但表內會存放一個鍵值，該鍵指向 Customer 表里包含該客戶信息的那一行。事實上，如果過程是數(shù)據(jù)驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。當然，也別做過頭了，比如 Customer_Shipping_Address_Street_Line_1，雖然很富有說明性，但沒人愿意鍵入這么長的名字，具體尺度就在你的把握中。你要讓客戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經常詢問客戶保證其需求仍然在開發(fā)的目的之中。 從輸入輸出下手在定義數(shù)據(jù)庫表和字段需求（輸入）時，首先應檢查現(xiàn)有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。創(chuàng)建 ER 圖表和數(shù)據(jù)字典確實有點費時但對其他開發(fā)人員要了解整個設計卻是完全必要的。了解你的企業(yè)業(yè)務可以在以后的開發(fā)階段節(jié)約大量的時間。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領域，比如人員、機構和工作效能等。檢查表名、報表名和查詢名之間的命名規(guī)范。 定義標準的對象命名規(guī)范一定要定義數(shù)據(jù)庫對象的命名規(guī)范。 第 3 部分 選擇鍵怎么選擇鍵呢？這里有 10 個技巧專門涉及系統(tǒng)生成的主鍵的正確用法，還有何 時以及如何索引字段以獲得最佳性能等。 CSDN 文檔中心 數(shù)據(jù)庫開發(fā) 閱讀：6246 評論： 4 參與評論 標題 數(shù)據(jù)庫設計經驗 選擇自 xlovem 的 Blog 關鍵字 數(shù)據(jù)庫設計經驗 出處 一個成功的管理系統(tǒng)，是由：[50% 的業(yè)務 + 50% 的軟件] 所組成，而 50% 的成功軟件又有 [25% 的數(shù)據(jù)庫 + 25% 的程序] 所組成，數(shù)據(jù)庫設計的好壞是一個關鍵。 第 4 部分 保證數(shù)據(jù)完整性討論如何保持數(shù)據(jù)庫的清晰和健壯，如何把有害數(shù)據(jù)降低到最小程度。對數(shù)據(jù)庫表來說，從項目一開始就要確定表名是采用復數(shù)還是單數(shù)形式。你可能會很快就被這些不同的數(shù)據(jù)庫要素的名稱搞糊涂了。其他的你還可以參考：[1]薩師煊　王珊著　數(shù)據(jù)庫系統(tǒng)概論(第二版)高等教育出版社 199[2][美] Steven 著 Oracle 7 與客戶／服務器計算技術從入門到精通　劉建元等譯　電子工業(yè)出版社，199[3]周中元　信息系統(tǒng)建模方法(下)　電子與信息化　1999年第3期，1999 暢想未來，但不可忘了過去的教訓我發(fā)現(xiàn)詢問用戶如何看待未來需求變化非常有用。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數(shù)據(jù)庫的人都明確如何從數(shù)據(jù)庫中獲得數(shù)據(jù)。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。一個不變的真理是：“只有我看見了我才知道我想要的是什么”必然會導致大量的返工，因為數(shù)據(jù)庫沒有達到客戶從來沒有寫下來的需求標準。 采用前綴命名如果多個表里有好多同一類型的字段（比如 FirstName），你不妨用特定表的前綴（比如 CusLastName）來幫助你標識字段。 標準化不能過頭對那些不熟悉標準化一詞（normalization）的人而言，標準化可以保證表內的字段都是最基礎的要素，而這一措施有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。更高層次的標準化也有，但更標準是否就一定更好呢？答案是不一定。這樣，當你用向導程序 [Wizards，臺灣人稱為‘精靈’] 創(chuàng)建表單和報表時，其名字會讓那些不是程序員的人更容易閱讀。 采用常用實體