數據庫技術是信息資源管理最有效的手段。
數據庫設計是指:對於給定的應用環境，構造最優的數據庫模式，建立數據庫及其應用系統，有效存儲數據，滿足用戶的信息要求和處理要求。
數據庫設計的階段:
A.需求分析階段:綜合每個用戶的應用需求(現實需求)。
B.在概念設計階段，形成壹個獨立於機器和DBMS產品的概念模型(信息世界模型)，並用E-R圖描述。
C.在邏輯設計階段，將E-R圖轉化為特定數據庫產品支持的數據模型，如關系模型，形成數據庫邏輯模型。然後根據用戶的處理需求和安全考慮，在基本表的基礎上建立必要的視圖，形成數據的外部模式。
d、在物理設計階段:根據DBMS的特點和處理的需要，安排物理存儲，設計索引，形成數據庫中的模式。
1.需求分析階段
需求收集和分析產生由數據字典描述的數據需求(以及由數據流圖描述的處理需求)。
需求分析的重點是調查、收集和分析用戶在數據管理方面的信息需求、處理需求、安全性和完整性需求。
需求分析的方法:調查各部門的組織和業務活動，協助用戶明確對新系統的各種需求，確定新系統的邊界。
常用的調查方法有:做作業、召開調查會、請人介紹、提問、設計問卷讓用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要有自頂向下和自底向上兩種。自頂向下結構化方法(SA)方法從頂層系統組織入手，通過逐層分解來分析系統，並用數據流圖和數據字典來描述每壹層。
數據流圖表達了數據和處理之間的關系。系統中的數據通過數據字典(DD)來描述。
2.概念結構設計階段
通過對用戶需求的綜合、歸納和抽象，形成壹個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於對信息世界進行建模。概念模型不依賴於DBMS支持的數據模型。概念模型可以轉換成計算機上的DBMS支持的特定數據模型。
概念模型的特征:
(1)具有很強的語義表達能力，可以方便、直接地表達應用中的各種語義知識。
(2)應該簡單明了，便於用戶理解，是用戶與數據庫設計者交流的語言。
概念模型設計的壹種常用方法是IDEF1X方法，這是壹種將實體-關系方法應用於語義數據模型建立系統信息模型的語義建模技術。
作者:曉玲，來源:論壇，編輯:李淑勤，2007-09-27 15:17。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
2.1步零初始化項目
這壹階段的任務是確定建模目標，制定建模計劃，組織建模團隊，收集源材料，從目的和範圍的描述中制定約束和規範。收集素材是這個階段的重點。通過調查觀察結果、業務流程、原系統的輸入輸出、各種報表，收集原始數據，形成基礎數據表。
2.2步驟1-定義實體
實體集的所有成員都有壹組彼此相同的特征和屬性，大多數實體都可以從收集的源材料-基礎數據表中直接或間接識別出來。根據源物料名稱列表中表示對象的術語和以“代碼”結尾的術語，如客戶代碼、代理商代碼、產品代碼等，識別其名詞所代表的實體，初步找出潛在的實體，形成初步的實體列表。
2.3第二步-定義連接
IDEF1X模型中只允許二進制連接，n進制連接必須定義為n個二進制連接。根據實際業務需求和規則，利用實體聯系矩陣識別實體間的二元關系，然後根據實際情況確定連接關系的勢、關系名稱和描述，確定關系類型，是已識別關系、未標記關系(強制或可選)還是不確定關系、已分類關系。如果子實體的每個實例都需要通過與父實體的關系來標識，則為標識關系，否則為非標識關系。在非標識關系中，如果子實體的每個實例只與壹個父實體相關聯，則它是強制的，否則它不是強制的。如果父實體和子實體表示相同的真實對象，那麽它們被分類。
2.4步驟3-定義代碼
通過引入交叉實體去除前壹階段產生的不確定關系，然後從非交叉實體和獨立實體中識別候選代碼的屬性，唯壹標識每個實體的實例，再從候選代碼中確定主代碼。為了確定主體代碼和關系的有效性，通過非空規則和非多值規則來保證，即實體實例的壹個屬性不能為空，也不能同時有多個值。找出誤識別的確定關系，進壹步分解實體，最終構建IDEF1X模型的關鍵基礎視圖(KB圖)。
2.5步驟4-定義屬性
從源數據表中提取描述性名詞，開發屬性表，確定屬性的所有者。定義非主鍵屬性，並檢查屬性的非空和非多值規則。此外，還需要檢查完全依賴函數和非傳遞依賴的規則，以確保壹個非主代碼屬性必須依賴於主代碼、整個主代碼且僅依賴於主代碼。這樣就得到改進的IDEF1X模型的全屬性視圖，它至少符合關系理論的第三範式。
2.6步驟5-定義其他對象和規則
定義數據類型、長度、精度、非空值、默認值、約束規則等。屬性的。定義對象信息，如觸發器、存儲過程、視圖、角色、同義詞和序列。
3.邏輯結構設計階段
將概念結構轉換成DBMS支持的數據模型(如關系模型),並對其進行優化。在設計邏輯結構時，要選擇最適合描述和表達相應概念結構的數據模型，進而選擇最適合的DBMS。
將E-R圖轉換成關系模型，實際上就是將實體、實體的屬性以及實體之間的關系轉換成關系模型。這種轉換壹般遵循以下原則:將實體轉換為關系模型。實體的屬性就是關系的屬性。實體的代碼就是關系的代碼。
優化數據模型，確定數據依賴，消除冗余連接，確定每個關系模式屬於哪個範式。確定是合並還是分解它們。壹般來說，這種關系被分解成3NF個標準，即:
表中的每個值只能表示壹次。
表中的每壹行都應該唯壹標識(用唯壹的鍵)。
依賴於其他鍵的非鍵信息不應存儲在表中。
作者:曉玲，來源:論壇，編輯:李淑勤，2007-09-27 15:17。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
4.數據庫物理設計階段
為邏輯數據模型選擇最適合應用環境的物理結構(包括存儲結構和訪問方法)。根據數據庫管理系統的特點和處理的需要，進行物理存儲安排和索引設計，形成數據庫中的模式。
5.數據庫實施階段
利用DBMS提供的數據語言(如SQL)及其宿主語言(如C)，根據邏輯設計和物理設計的結果建立數據庫，編譯調試應用程序，數據入庫並投入試運行。數據庫的實現主要包括以下任務:用DDL定義數據庫結構，組織數據存儲，編譯調試應用程序，數據庫試運行(DDL(數據定義語言)用於打開新的數據表，設置字段，刪除數據表，刪除字段，管理所有與數據庫結構相關的事情)。
●創建(補充壹些關於數據庫結構的東西，屬於DDL)
●Drop(刪除壹些關於數據庫結構的東西，DDL)
●改變(改變結構，DDL)
6.數據庫操作和維護階段
數據庫系統在運行期間必須不斷評估、調整和修改。內容包括:數據庫轉儲與恢復、數據庫安全與完整性控制、數據庫性能監控、分析與改進、數據庫重組與重構。
7.建模工具的使用
目前有很多加速數據庫設計的數據庫輔助工具(CASE tools)，如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圖。
數據字典(DD)是各種數據描述的集合，是關於數據庫中數據的描述，也就是元數據，而不是數據本身。(至少應包括每個字段的數據類型和每個表中的主外鍵)。
數據項描述:數據項名稱、數據項含義描述、別名、數據類型、長度、取值範圍、取值含義以及與其他數據項的邏輯關系。
數據結構描述:數據結構名稱、含義描述、組成:[數據項或數據結構]
數據流描述:數據流名稱、描述、數據流來源、數據流目的地、組成:【數據結構】、平均流量、峰值流量。
數據存儲描述:數據存儲名稱、描述、編號、流入數據流、流出數據流、組成:【數據結構】、數據量、訪問方式。
處理過程描述:處理過程名稱，描述，輸入:[數據流]，輸出:[數據流]，處理:[簡要描述]
ER圖表和數據字典可以讓任何了解數據庫的人清楚如何從數據庫中獲取數據。ER圖表對於顯示表之間的關系非常有用，而數據字典顯示每個字段的用途和任何可能的別名。這對於SQL表達式的文檔來說是絕對必要的。
5)定義標準的對象命名規範。
數據庫中各種對象的命名必須標準化。
作者:曉玲，來源:論壇，編輯:李淑勤，2007-09-27 15:17。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
2.表和字段的設計(數據庫邏輯設計)
表格設計原則
1)標準化和規範化
數據標準化有助於消除數據庫中的數據冗余。標準化有幾種形式，但第三範式(3NF)通常被認為是性能、可伸縮性和數據完整性之間的最佳平衡。簡單來說，符合3NF標準的數據庫的表設計原則是:“壹個地方壹個事實”，即壹個表只包含自己的基本屬性，當不是自己的屬性時需要分解。表之間的關系由外鍵連接。它有以下幾個特點:有壹組專門存儲相關數據的表，用鍵連接。
2)數據驅動
用數據驅動代替硬編碼，很多策略修改和維護會方便很多，大大增強了系統的靈活性和擴展性。
例如，如果用戶界面想要訪問外部數據源(文件、XML文檔、其他數據庫等)。)，建議將相應的連接和路徑信息存儲在用戶界面支持的表中。如果用戶界面執行諸如工作流(發送郵件、打印信紙、修改記錄狀態等)的任務。)，那麽生成工作流的數據也可以存儲在數據庫中。角色權限管理也可以通過數據驅動來完成。事實上，如果流程是數據驅動的，您可以將相當大的責任放在用戶身上，他們將維護自己的工作流程。
3)考慮各種變化
設計數據庫時，要考慮哪些數據字段將來可能會發生變化。
4)表名、報表名和查詢名的命名規範。
(以前綴命名)檢查表名、報表名和查詢名之間的命名規範。您可能很快會被這些不同的數據庫元素的名稱弄糊塗。您可以統壹命名這些數據庫的不同組件，至少您應該在這些對象名稱的開頭使用前綴如Table、Query或Report來區分它們。如果采用Microsoft Access，可以用qry、rpt、tbl、mod等符號來標識對象(如tbl_Employees)。用sp_company標識存儲過程，用udf_(或者類似的標簽)標識自定義編寫的函數。
現場設計原則:
1)每個表中應該添加的三個有用字段。
DRecordCreationDate，默認為SQL Server下的GETDATE()。
SRecordCreator，默認為SQL Server下的NOT NULL默認用戶。
NRecordVersion，記錄的版本標記；準確解釋記錄中出現空數據或缺失數據的原因很有幫助。
及時性數據應包括“最後更新日期/時間”字段。時間戳對於查找數據問題的原因、按日期重新處理/重新加載數據以及清除舊數據特別有用。
2)對地址和電話號碼使用多個字段。
僅僅用壹行來描述街道地址是不夠的。Address_Line1、Address_Line2和Address_Line3可以提供更大的靈活性。此外，電話號碼和電子郵件地址應該有自己的數據表，有自己的類型和標簽類別。
3)表中列[字段]的命名規則(以前綴/後綴命名)和有意義的字段名。
列[字段]名稱應該使用標準的前綴和後綴。如果鍵是數字，使用_N後綴；字符類型:_C後綴；日期類型:_D後綴。再比如，如果妳的表中有很多“money”字段，不妨給每壹列[字段]加壹個_M後綴。
作者:曉玲，來源:論壇，編輯:李淑勤，2007-09-27 15:17。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
假設有兩個表:
客戶和訂單。客戶表的前綴是cu_，所以表中的子段名如下:cu_name_id，cu_surname，cu_initials，cu_address。訂單表的前綴是或_，因此子部分的名稱是:
Or_order_id，or_cust_name_id，or_quantity和or_description等。
從數據庫中選擇所有數據的SQL語句可以寫成如下形式:
Select * From Customer，Order Where cu _ surname = " MYNAME
並且cu_name_id = or_cust_name_id和or_quantity = 1
如果沒有這些前綴，它看起來像這樣(通過別名區分):
Select * From Customer，Order Where Customer . surname = " my name "；
並且customer . name _ id = order . cust _ name _ id和Order.quantity = 1
第1條SQL語句沒有缺少很多字符。但是如果查詢涉及五個表或者更多的列[字段]，妳就會知道這種技術有多有用。
5)選擇的數字類型和文本類型的長度要盡可能足夠。
假設客戶ID的長度為10位數字。然後，您應該將數據庫表字段的長度設置為12或13個字符。但是，這額外的空間並不需要在未來重建整個數據庫來實現數據庫規模的增長。
6)添加刪除標記字段。
在表中包含刪除標記字段，以便可以將行標記為刪除。不要刪除關系數據庫中的任何壹行；最好使用數據清理程序，並小心維護索引的完整性。
7)註意混合大小寫的對象名和特殊字符。
全大寫和下劃線的名稱可讀性更好(CUSTOMER_DATA)。永遠不要在對象名的字符之間留空格。
8)小心用詞。
確保您的字段名不與保留字、數據庫系統或常用訪問方法沖突，例如，使用DESC作為描述字段名。後果可想而知！DESC是降序縮寫後的保留字。可以使用表中的SELECT *語句，但是會得到很多無用的信息。
9)保持字段名和類型的壹致性。
在為字段命名和指定數據類型時，壹定要保持壹致。如果表1中的字段名為“agreement_number”，則不要將表2中的名稱更改為“ref1”。如果表1中的數據類型是整數，不要將其更改為表2中的字符類型。當然，表1(ABC)中有壹個key ID，為了可讀性，在表2中做關聯時可以命名為ABC_ID。
10)避免使用觸發器。
觸發器的功能通常可以通過其他方式實現。調試程序時，觸發器可能會成為幹擾。如果妳真的需要使用觸發器，妳最好專註於記錄它。
作者:曉玲，來源:論壇，編輯:李淑勤，2007-09-27 15:17。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
3.選擇鍵和索引(數據庫邏輯設計)
參考:文章“SQL優化-索引”
4.數據完整性設計(數據庫邏輯設計)
1)完整性實現機制:
實體完整性:主鍵
參照完整性:
刪除父表中的數據:級聯刪除；限制性刪除；空值
將數據插入父表:受限插入；遞歸插入
更新父表中的數據:級聯更新；受限更新；空值
DBMS可以通過兩種方式實現參照完整性:外鍵實現機制(約束規則)和觸發器實現機制用戶定義的完整性:
不為空；檢查；引發
2)通過約束而不是業務規則來加強數據完整性。
利用數據庫系統實現數據完整性。這不僅包括通過標準化實現的完整性，還包括數據的功能性。不依賴業務層保證數據完整性；它不能保證表(外鍵)之間的完整性，所以不能強加在其他完整性規則上。如果您確實在數據層中使用了約束，那麽您應該確保有壹種方法可以用壹種用戶能夠理解為什麽更新不能通過約束檢查的語言來通知用戶界面。
3)強制性指示完整性
在有害數據進入數據庫之前將其消除。激活數據庫系統指示的完整性特征。這可以保持數據的整潔，並迫使開發人員花費更多的時間來處理錯誤情況。
4)使用查找來控制數據完整性。
控制數據完整性的最好方法是限制用戶的選擇。只要有可能，就應該為用戶提供壹個清晰的值列表以供選擇。這將減少鍵入代碼時的錯誤和誤解，並提供數據壹致性。壹些公共數據特別適合搜索:國家代碼、狀態代碼等。
5)采納觀點
為了在數據庫和應用程序代碼之間提供另壹個抽象層，可以為應用程序建立壹個特殊的視圖，而無需應用程序直接訪問數據表。這樣做還可以讓您在處理數據庫更改時更加自由。
6)分布式數據系統
對於分布式系統，在決定是復制每個站點中的所有數據還是將數據保存在壹個地方之前，您應該估計未來五年或10年的數據量。當妳向其他站點發送數據時，妳最好在數據庫字段中設置壹些標簽，並在目的站點收到妳的數據後更新妳的標簽。對於這種數據傳輸，請寫下您自己的批處理或調度程序，以在特定的時間間隔運行，而不是讓用戶在每天工作後傳輸數據。把妳的維護數據復制到本地，比如計算常數和利率，設置版本號，保證每個站點的數據完全壹致。
7)關系
如果兩個實體之間是多對壹的關系，而且有可能轉化成多對多的關系，那麽妳最好壹開始就設置成多對多的關系。從現有的多對壹關系轉變為多對多關系比從多對多關系開始要困難得多。
8)制定數據保留和恢復計劃。
考慮數據保存策略並將其包括在設計過程中，並提前設計您的數據恢復過程。使用壹個可以發布給用戶/開發者的數據字典，可以實現方便的數據識別，保證數據源的文檔化。編寫“更新查詢”的在線更新，以便在以後數據丟失時可以重新處理更新。
9)使用存儲過程讓系統做繁重的工作
為訪問組提供壹組傳統的存儲過程，以便加速和簡化客戶端程序代碼的開發。數據庫不僅是存儲數據的地方，也是簡化編碼的地方。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
5.其他設計技能
1)避免使用觸發器。
觸發器的功能通常可以通過其他方式實現。調試程序時，觸發器可能會成為幹擾。如果妳真的需要使用觸發器，妳最好專註於記錄它。
2)使用通用英語(或任何其他語言)代替編碼。
創建下拉菜單、列表和報表時，最好按英文名稱排序。如果需要編碼，可以在編碼中附上用戶認識的英文。
3)保存常用信息
擁有壹個專用於壹般數據庫信息的表非常有用。在該表中，存儲了數據庫的當前版本、最新檢查/維修(用於訪問)、相關設計文檔的名稱、客戶和其他信息。這可以實現壹個簡單的機制來跟蹤數據庫，當客戶抱怨他們的數據庫不符合期望的要求並與您聯系時，這對於非客戶機/服務器環境尤其有用。
4)包括版本機制
版本控制機制被引入到數據庫中，以確定正在使用的數據庫的版本。隨著時間的推移，用戶的需求總是會發生變化。您最終可能需要修改數據庫結構。將版本信息直接存儲在數據庫中更方便。
5)文件準備
記錄所有快捷方式、命名約定、限制和功能。
使用數據庫工具來註釋表、列、觸發器等。對於開發、支持和跟蹤變更非常有用。
記錄數據庫，或者在數據庫內部或單獨建立文檔。這樣壹年多以後妳再去找第二個版本的時候，出錯的幾率會大大降低。
6)測試、試驗和重復試驗
建立或修改數據庫後，必須用用戶新輸入的數據測試數據字段。最重要的是，讓用戶測試並與用戶壹起工作，以確保所選擇的數據類型滿足業務需求。在將新數據庫投入實際服務之前，需要完成測試。
7)檢查設計
在開發過程中檢查數據庫設計的壹種常見技術是通過數據庫支持的應用程序原型來檢查數據庫。換句話說，對於每個最終表達數據的原型應用程序，請確保檢查數據模型並了解如何提取數據。
第三，數據庫命名規範
1.實體(表)的命名
1)表格以名詞或名詞短語命名，確定表格名稱是復數還是單數。此外，為表的別名定義了簡單的規則(例如，如果表名是壹個單詞，別名取單詞的前四個字母；如果表名是兩個單詞，取每個單詞的前兩個字母組成四個字母的別名；如果表名由三個單詞組成，從前兩個單詞中取壹個，然後從最後壹個單詞中取兩個字母，結果仍然是四個字母的別名，依此類推)
對於工作表，表名可以以WORK_為前綴，後跟使用該表的應用程序的名稱。在命名過程中，縮略語可以根據語義拼湊。註意:字段名會統壹成大寫或小寫，所以中間加下劃線。
作者:曉玲，來源:論壇，編輯:李淑勤，2007-09-27 15:17。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
例如:
定義的縮寫Sales:Sal Sales；
秩序:Ord秩序；
細節:Dtl細節；
然後將銷售訂單列表命名為:薩爾_ Ord _ Dtl；
2)如果表或字段的名稱只有壹個單詞，建議使用完整的單詞，不要使用縮寫。
例如:
定義的縮寫材料Ma文章；
項目列表被稱為物料，而不是Ma。
但是字段項目編碼是:Ma _ ID不是物料ID。
3)在所有存儲值列表的表前面加上前綴Z。
目的是在數據庫末尾對這些值列表分類進行排序。
4)在命名所有冗余類(主要是累積表)之前加上前綴X
冗余類是在數據庫非規範化時添加的字段或表，目的是提高數據庫的效率。
5)通過用下劃線連接兩個基本類，然後添加前綴R，然後按字母順序列出兩個表名或表名的縮寫來命名關聯的類。
關聯表用於存儲多對多關系。
如果關聯的表名超過10個字母，則原始表名必須縮寫。如果沒有其他原因，建議使用縮寫。
例如，如果表對象與其自身之間存在多對多關系，則保存多對多關系的表被命名為:R _ Object
作者:曉玲，來源:論壇，編輯:李淑勤，2007-09-27 15:17。
本文詳細分析了數據庫設計過程和技巧，並總結了數據庫命名標準...
2.屬性(列)的命名
1)采用有意義的列名。
表中的列應該采用壹組鍵的設計規則。每個表將有壹個自動ID作為主鍵，邏輯主鍵將被定義為第壹組候選主鍵。
A.如果代碼由數據庫自動生成，則統壹命名為ID。
b、如果是用戶自定義的邏輯代碼，則用縮寫和“ID”命名，即“XXXX_ID”。
c、如果鍵是數字類型，可以用_NO做後綴；
d，如果是字符型，可以用後綴_CODE。
e列名應該使用標準的前綴和後綴。
例如，銷售訂單的數字字段命名為薩爾_ Ord _ ID；如果仍有數據庫自動生成的數字，則將其命名為:ID。
2)所有屬性都以相關類型作為後綴。
註意，如果需要其他後綴，它們應該放在類型後綴之前。
註意:數據類型是文本字段，類型後綴TX可以省略。對於壹些類型比較明顯的字段，不需要寫類型後綴。
3)采用前綴命名
對每個表的列名使用統壹的前綴將大大簡化SQL表達式的編寫。它確實有缺點，例如破壞了自動表連接工具的功能，該工具將公共列名與壹些數據庫鏈接起來。
3.視圖的命名
1)視圖以V為前綴，其他命名規則與表相似；
2)命名要盡可能體現每個視圖的功能。
4.觸發器的命名(盡量不要使用它們)
觸發器前綴為TR，觸發器名稱為對應的帶後綴的表名，插入觸發器加' _I '，刪除觸發器加' _D '，更新觸發器加' _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)保持字段名和類型的壹致性，在為字段命名和指定數據類型時，壹定要保證壹致性。如果壹個表中的數據類型是整數，不要在另壹個表中將其更改為字符類型。
參考資料:
開發者在線