資料庫表起名

Ⅰ 資料庫命名規則

對於資料庫的設計中，盡量不用漢字，最好用英文，如果用漢字，有時會產生不必要的麻煩，可能產生插入，刪除等等異常，而且在寫存儲過程或觸發器等等也許會產生錯誤，以下對設計表和欄位的一些規則，可能對提問者用幫助：
1. 檢查各種變化
我在設計資料庫的時候會考慮到哪些數據欄位將來可能會發生變更。比方說，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統存儲客戶信息時，我傾向於在單獨的一個數據表裡存儲姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一數據條目的變化。
2. 採用有意義的欄位名
有一回我參加開發過一個項目，其中有從其他程序員那裡繼承的程序，那個程序員喜歡用屏幕上顯示數據指示用語命名欄位，這也不賴，但不幸的是，她還喜歡用一些奇怪的命名法，其命名採用了匈牙利命名和控制序號的組合形式，比如 cbo1、txt2、txt2_b 等等。
除非你在使用只面向你的縮寫欄位名的系統，否則請盡可能地把欄位描述的清楚些。當然，也別做過頭了，比如 Customer_Shipping_Address_Street_Line_1，雖然很富有說明性，但沒人願意鍵入這么長的名字，具體尺度就在你的把握中。
3. 採用前綴命名
如果多個表裡有好多同一類型的欄位（比如 FirstName），你不妨用特定表的前綴（比如 CusLastName）來幫助你標識欄位。

時效性數據應包括「最近更新日期/時間」欄位。時間標記對查找數據問題的原因、按日期重新處理/重載數據和清除舊數據特別有用。
4. 標准化和數據驅動
數據的標准化不僅方便了自己而且也方便了其他人。比方說，假如你的用戶界面要訪問外部數據源（文件、XML 文檔、其他資料庫等），你不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有，如果用戶界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的數據也可以存放在資料庫里。預先安排總需要付出努力，但如果這些過程採用數據驅動而非硬編碼的方式，那麼策略變更和維護都會方便得多。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
5. 標准化不能過頭
對那些不熟悉標准化一詞（normalization）的人而言，標准化可以保證表內的欄位都是最基礎的要素，而這一措施有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但 Third Normal Form（3NF）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，3NF 規定：
* 表內的每一個值都只能被表達一次。
* 表內的每一行都應該被唯一的標識（有唯一鍵）。
* 表內不應該存儲依賴於其他鍵的非鍵信息。
遵守 3NF 標準的資料庫具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。比方說，某個存放客戶及其有關定單的 3NF 資料庫就可能有兩個表：Customer 和 Order。Order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向 Customer 表裡包含該客戶信息的那一行。
更高層次的標准化也有，但更標準是否就一定更好呢？答案是不一定。事實上，對某些項目來說，甚至就連 3NF 都可能給資料庫引入太高的復雜性。

為了效率的緣故，對表不進行標准化有時也是必要的，這樣的例子很多。曾經有個開發餐飲分析軟體的活就是用非標准化表把查詢時間從平均 40 秒降低到了兩秒左右。雖然我不得不這么做，但我絕不把數據表的非標准化當作當然的設計理念。而具體的操作不過是一種派生。所以如果表出了問題重新產生非標准化的表是完全可能的。
6. Microsoft Visual FoxPro 報表技巧
如果你正在使用 Microsoft Visual FoxPro，你可以用對用戶友好的欄位名來代替編號的名稱：比如用 Customer Name 代替 txtCNaM。這樣，當你用向導程序 [Wizards，台灣人稱為『精靈』] 創建表單和報表時，其名字會讓那些不是程序員的人更容易閱讀。
7. 不活躍或者不採用的指示符
增加一個欄位表示所在記錄是否在業務中不再活躍挺有用的。不管是客戶、員工還是其他什麼人，這樣做都能有助於再運行查詢的時候過濾活躍或者不活躍狀態。同時還消除了新用戶在採用數據時所面臨的一些問題，比如，某些記錄可能不再為他們所用，再刪除的時候可以起到一定的防範作用。
8. 使用角色實體定義屬於某類別的列[欄位]
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
這里的含義不是讓 PERSON 實體帶有 Title 欄位，而是說，為什麼不用 PERSON 實體和 PERSON_TYPE 實體來描述人員呢？比方說，當 John Smith, Engineer 提升為 John Smith, Director 乃至最後爬到 John Smith, CIO 的高位，而所有你要做的不過是改變兩個表 PERSON 和 PERSON_TYPE 之間關系的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的 PERSON_TYPE 表就包含了所有 PERSON 的可能類型，比如 Associate、Engineer、Director、CIO 或者 CEO 等。
還有個替代辦法就是改變 PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。

• 採用常用實體命名機構數據
組織數據的最簡單辦法就是採用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。當你把這些常用的一般名字組合起來或者創建特定的相應副實體時，你就得到了自己用的特殊版本。開始的時候採用一般術語的主要原因在於所有的具體用戶都能對抽象事物具體化。
有了這些抽象表示，你就可以在第 2 級標識中採用自己的特殊名稱，比如，PERSON 可能是 Employee、Spouse、Patient、Client、Customer、Vendor 或者 Teacher 等。同樣的，ORGANIZATION 也可能是 MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。最後 ADDRESS 可以具體為 Site、Location、Home、Work、Client、Vendor、Corporate 和 FieldOffice 等。
採用一般抽象術語來標識「事物」的類別可以讓你在關聯數據以滿足業務要求方面獲得巨大的靈活性，同時這樣做還可以顯著降低數據存儲所需的冗餘量。
• 用戶來自世界各地
在設計用到網路或者具有其他國際特性的資料庫時，一定要記住大多數國家都有不同的欄位格式，比如郵政編碼等，有些國家，比如紐西蘭就沒有郵政編碼一說。
• 數據重復需要採用分立的數據表
如果你發現自己在重復輸入數據，請創建新表和新的關系。
• 每個表中都應該添加的 3 個有用的欄位
* dRecordCreationDate，在 VB 下默認是 Now()，而在 SQL Server 下默認為 GETDATE()
* sRecordCreator，在 SQL Server 下默認為 NOT NULL DEFAULT USER
* nRecordVersion，記錄的版本標記；有助於准確說明記錄中出現 null 數據或者丟失數據的原因
• 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。

過分標准化可要小心，這樣做可能會導致性能上出現問題。雖然地址和電話表分離通常可以達到最佳狀態，但是如果需要經常訪問這類信息，或許在其父表中存放「首選」信息（比如 Customer 等）更為妥當些。非標准化和加速訪問之間的妥協是有一定意義的。
• 使用多個名稱欄位
我覺得很吃驚，許多人在資料庫里就給 name 留一個欄位。我覺得只有剛入門的開發人員才會這么做，但實際上網上這種做法非常普遍。我建議應該把姓氏和名字當作兩個欄位來處理，然後在查詢的時候再把他們組合起來。

我最常用的是在同一表中創建一個計算列[欄位]，通過它可以自動地連接標准化後的欄位，這樣數據變動的時候它也跟著變。不過，這樣做在採用建模軟體時得很機靈才行。總之，採用連接欄位的方式可以有效的隔離用戶應用和開發人員界面。
• 提防大小寫混用的對象名和特殊字元
過去最令我惱火的事情之一就是資料庫里有大小寫混用的對象名，比如 CustomerData。這一問題從 Access 到 Oracle 資料庫都存在。我不喜歡採用這種大小寫混用的對象命名方法，結果還不得不手工修改名字。想想看，這種資料庫/應用程序能混到採用更強大資料庫的那一天嗎？採用全部大寫而且包含下劃符的名字具有更好的可讀性（CUSTOMER_DATA），絕對不要在對象名的字元之間留空格。
• 小心保留詞
要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突，比如，最近我編寫的一個 ODBC 連接程序里有個表，其中就用了 DESC 作為說明欄位名。後果可想而知！DESC 是 DESCENDING 縮寫後的保留詞。表裡的一個 SELECT * 語句倒是能用，但我得到的卻是一大堆毫無用處的信息。
• 保持欄位名和類型的一致性
在命名欄位並為其指定數據類型的時候一定要保證一致性。假如欄位在某個表中叫做「agreement_number」，你就別在另一個表裡把名字改成「ref1」。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。記住，你幹完自己的活了，其他人還要用你的資料庫呢。
• 仔細選擇數字類型
在 SQL 中使用 smallint 和 tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額欄位類型是 smallint，那麼，如果總額超過了 $32,767 你就不能進行計算操作了。
• 刪除標記
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。
• 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
• 包含版本機制
建議你在資料庫中引入版本控制機制來確定使用中的資料庫的版本。無論如何你都要實現這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。雖然你可以通過檢查新欄位或者索引來確定資料庫結構的版本，但我發現把版本信息直接存放到資料庫中不更為方便嗎？。
• 給文本欄位留足餘量
ID 類型的文本欄位，比如客戶 ID 或定單號等等都應該設置得比一般想像更大，因為時間不長你多半就會因為要添加額外的字元而難堪不已。比方說，假設你的客戶 ID 為 10 位數長。那你應該把資料庫表欄位的長度設為 12 或者 13 個字元長。這算浪費空間嗎？是有一點，但也沒你想像的那麼多：一個欄位加長 3 個字元在有 1 百萬條記錄，再加上一點索引的情況下才不過讓整個資料庫多佔據 3MB 的空間。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。身份證的號碼從 15 位變成 18 位就是最好和最慘痛的例子。
• 列[欄位]命名技巧
我們發現，假如你給每個表的列[欄位]名都採用統一的前綴，那麼在編寫 SQL 表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列[欄位]名同某些資料庫聯系起來，不過就連這些工具有時不也連接錯誤嘛。舉個簡單的例子，假設有兩個表：
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 個表乃至更多的列[欄位]你就知道這個技巧多有用了。

Ⅱ 怎樣列出資料庫的全部表名 詳細

列出資料庫的全部表名
select name from sysobjects where type='u'
select count(*) from sysobjects where id = object_id('資料庫名.Owner.表名')OBJECT_ID返回資料庫對象標識號。
語法_ID ( 'object' )參數'object'要使用的對象。object 的數據類型為 char 或 nchar。如果 object 的數據類型是 char，那麼
隱性將其轉換成 nchar。
返回類型int注釋當該參數對系統函數可選時，則系統採用當前資料庫、主機、伺服器用戶或資料庫用戶。內
置函數後面必須跟圓括弧。
如果指定一個臨時表名，則必須在臨時表名前面加上資料庫名，例如：
SELECT OBJECT_ID('tempdb..#mytemptable')
系統函數可以在選擇列表、WHERE 子句和任何允許使用表達式的地方使用。有關更多信
息，請參見表達式和 WHERE。
示例下面的示例為 pubs 資料庫中的 authors 表返回對象 ID。
USE masterSELECT OBJECT_ID('pubs..authors')
下面是結果集：

Ⅲ 怎麼用Sql語句獲取一個資料庫中的所有表的名字

查詢資料庫里所有表名和欄位名的語句

1.SQL 查詢所有表名：
SELECT NAME FROM SYSOBJECTS WHERE TYPE='U'
SELECT * FROM INFORMATION_SCHEMA.TABLES

2.查詢表的所有欄位名：
SELECT NAME FROM SYSCOLUMNS WHERE ID=OBJECT_ID(' 表名' )
SELECT * FROM INFORMATION_SCHEMA.TABLES
SELECT * FROM INFORMATION_SCHEMA.VIEWS
SELECT * FROM INFORMATION_SCHEMA.COLUMNS

3.ORACLE 查看所有表名:
SELECT TABLE_NAME FROM USER_TABLES

4.ACCESS 查看所有表名：
SELECT NAME FROM MSYSOBJECTS WHERE TYPE=1 AND FLAGS=0

5.MSYSOBJECTS 是系統對象，默認情況是隱藏的。通過工具、選項、視圖、顯示、系統對象可以使之顯示出來。

Ⅳ 資料庫表的命名規范，表名要不要加s

public void actionPerformed(ActionEvent e)
{
if(e.getSource()==xinjian)
{
text.setText("");
}
if(e.getSource()==dakai)
{
openFD.show();
String s;

Ⅳ 如何為資料庫取名

在資料庫中創建對象時，管理員也要對其進行取名。現在談談取名的一些技巧。 一、表名大小寫的控制 一般情況下Oracle資料庫中的表名或者列名是不區分大小寫的。在創建表或者列的時候，即使管理員採用了小寫的名字，資料庫在將其保存到數據字典之前，會先將其轉換為大寫，再將他們保存到數據字典中。這也就是為什麼我們取名使用小寫的子母取名，但是下次查看錶的名字的時候，卻變成了大寫。 雖然說Oracle資料庫中表與列等資料庫對象對於大小寫是不敏感的，但是如果資料庫管理員確實有需要要讓資料庫系統對表的名字區分大小寫，這也是可以做到的。通常情況下，如果把名字使用雙引號括起來，則在Oracle數據字典中就會成為區分大小寫的名字。不過筆者這里要提醒各位資料庫管理員，雖然說從技術上可以讓資料庫系統強製取分大小寫，但是在實際工作中，包括在內的絕大部分資料庫管理員可能都不建議這么做。因為如果有混合的大小寫存在，那麼在引用這些表或者列名稱的時候就需要特別的小心。因為即使用戶或者資料庫管理員有著過目不忘的本領，也很難准確的記住這些名稱的大小寫歌時。如果資料庫管理員硬要這么做的話，那麼很可能是自尋煩惱。在查詢時或者其他作業時，要嚴格區分大小寫那是一件很頭疼的事情。為此，對於這個大小寫的控制，筆者建議資料庫管理員要謹慎使用。除非有充分的理由，否則的話，不要輕易使用這個雙引號來控制大小寫。 這個雙引號不僅可以用來控制大小寫，還有一個比較特殊的作用，就是用引用一些特殊的字元。如在建立表格的時候，需要設置一個名牌號的欄位。有些資料庫管理員習慣使用num#類似的名稱。這不會違反資料庫的取名規則。不過在處理的時候會比較麻煩。如利用create語句建立表格的時候，需要給這個欄位名稱加上雙引號。否則的話，執行這條語句的時候，資料庫會拒絕執行並向用戶提示錯誤信息。類似的特殊符號還包括一個$美元符號。他們在建立表格的時候，在語句中都需要使用雙引號。不過欄位建立好之後，在引用這些對象的時候，不需要使用雙引號了。同理，雖然Oracle資料庫支持這些特殊符號，但是筆者不鼓勵資料庫管理員在表或者列的取名中採取這些特殊的符號。這有可能給後續的引用帶來不必要的麻煩。 二、牢記取名空間 在Oracle資料庫中，跟其他的資料庫不同，有一個叫做取名空間的概念。在同一個取名空間中，其名字不可以重復。如表與視圖就共享同一個取名空間，為此就要求不僅表的名字不能夠相同，而且表的名字與視圖的名字也不能夠相同。因為他們處於同一個取名空間。類似的，表與函數也是同處於一個表空間，為此他們也不能夠同名。不過表與索引、表與約束等等卻屬於不同的取名空間。也就是說，表的名字可以與約束的名字相同。所以說，資料庫管理員在給表等對象取名的時候，一定要了解哪些對象共享同一個名稱空間。如果在同一個名稱空間內的，即使對象不同(如視圖與表)，但是他們仍然不能夠取相同的名字。 為了避免同一個取名空間內重名的現象，筆者建立在取名的時候最好能夠根據對象的不同加上對象的固有前綴。如大部分的資料庫管理員，在給表取名的時候，一般不會表名前面加上表對象的前綴。但是在定義函數或者視圖對象的時候，則會加上前綴。如在函數前面可能會加上FN的前綴，而在視圖前面可能會加上vi的前綴。如此的話，在同一個取名空間內也不用擔心對象重名的問題。不過無論怎麼說，這個取名空間的概念資料庫管理員必須牢記。即使在實際的工作中，可以通過前綴等手段輕易的避免這個陷阱，但是在Oracle資料庫管理員的認證考試中，這個取名空間也是一個必要的知識點。所以無論從實際的工作還是認證考試的需要，對於這個取名空間管理員都必須要有一個清晰的認識。 三、在表、索引、約束、列之間設置密切的聯系 在創建表的同時，可以給表中的某些列添加索引、約束等等。如在員工信息表中，會設置員工編號唯一性約束。在創建約束的時候，也需要對約束進行取名。雖然說也約束與表、列不屬於同一個取名空間，所以在取名的時候基本上沒有限制。但是為了後續使用的方便，筆者對約束的取名還有一個小小的建議。簡單的說，就是給一個與表直接有關的其他對象具有該表的名字是一種好的做法。如現在有一張用戶表名字叫做ad_user(在表名前面一般不加對象名，但是可以根據應用軟體的模塊設計加上模塊的前綴)，這種表中有一個欄位叫做叫做vlaue，用來存儲員工的編號。在表設計的時候，需要給這個欄位加一個索引。那麼這個索引的名字就可以取名為IDX_USER_VALUE(也就是索引前綴+表名+欄位名的形式)。這么做有什麼好處呢?一是可以確保相關對象的名字不會重復。因為表的名字不會重復，所以將表的名字與列的名字一起組成某個對象的名字，那麼其重復的幾率可以說基本上沒有。二是方便管理員閱讀、理解、維護等等。一看到索引或者約束對象的名字時，就可以看到這個是索引或者約束是用在哪個表的那個欄位上的。而且也可以知道這個約束是唯一性約束還是檢查約束;索引時主鍵索引還是外鍵索引。給資料庫管理員一目瞭然的感覺。這對於後續的維護、升級、調整、引用等等都提供了方便。 雖然說Oracle資料庫中表與列等資料庫對象對於大小寫是不敏感的，但是如果資料庫管理員確實有需要要讓資料庫系統對表的名字區分大小寫，這也是可以做到的。通常情況下，如果把名字使用雙引號括起來，則在Oracle數據字典中就會成為區分大小寫的名字。不過筆者這里要提醒各位資料庫管理員，雖然說從技術上可以讓資料庫系統強製取分大小寫，但是在實際工作中，包括在內的絕大部分資料庫管理員可能都不建議這么做。因為如果有混合的大小寫存在，那麼在引用這些表或者列名稱的時候就需要特別的小心。因為即使用戶或者資料庫管理員有著過目不忘的本領，也很難准確的記住這些名稱的大小寫歌時。如果資料庫管理員硬要這么做的話，那麼很可能是自尋煩惱。在查詢時或者其他作業時，要嚴格區分大小寫那是一件很頭疼的事情。為此，對於這個大小寫的控制，筆者建議資料庫管理員要謹慎使用。除非有充分的理由，否則的話，不要輕易使用這個雙引號來控制大小寫。

Ⅵ 資料庫表名前綴是什麼意思

沒什麼意思 就是分辨表名
比如：
zd_
mp3_
wy_
zx_
------一看就知道是這個數據干什麼用的。

Ⅶ 如何重新給資料庫中的表命名啊

在企業管理里—表—右健

或

sp_rename '舊表','新表','object'

Ⅷ 資料庫里的表名和列名都是什麼

這么解釋，拿一個成績單舉例子：

成績單就是一個（表）
裡面的「班級 姓名 性別 功課 成績」就是（列）
每個人算一條記錄

這樣應該明白了吧。

Ⅸ 大家給我起幾個資料庫的表名

1 特徵項目描述表
Characteristic project description CPD
2 整數類型特徵項條目表
Integral type characteristic of entry form ITC
3 浮點類型特徵項條目表
Float type feature entry form FTF
4 分數類型特徵項條目表
Score type feature item lists STF
5 日期類型特徵項條目表
Date of entry form feature type DFT
6 名稱樹類型特徵項條目表
Name tree type feature items NTTFI
7 數值樹類型特徵項條目表
Numerical tree type feature entry form NTTFEF