A. 簡答：sql語言的特點
sql語言的特點：
1、SQL風格統一
SQL可以獨立完成資料庫生命周期中的全部活動，包括定義關系模式、錄入數據、建立資料庫、査詢、更新、維護、資料庫重構、資料庫安全性控制等一系列操作，這就為資料庫應用系統開發提供了良好的環境。
在資料庫投入運行後，還可根據需要隨時逐步修改模式，且不影響資料庫的運行，從而使系統具有良好的可擴充性。
2、高度非過程化
非關系數據模型的數據操縱語言是面向過程的語言，用其完成用戶請求時，必須指定存取路徑。而用SQL進行數據操作，用戶只需提出「做什麼」，而不必指明「怎麼做」。
因此用戶無須了解存取路徑，存取路徑的選擇以及SQL語句的操作過程由系統自動完成。這不但大大減輕了用戶負擔，而且有利於提高數據獨立性。
3、面向集合的操作方式
SQL採用集合操作方式，不僅查找結果可以是元組的集合，而且一次插入、刪除、更新操作的對象也可以是元組的集合。
4、以同一種語法結構提供兩種使用方式
SQL既是自含式語言，又是嵌入式語言。作為自含式語言，它能夠獨立地用於聯機交互的使用方式，用戶可以在終端鍵盤上直接輸入SQL命令對資料庫進行操作。
作為嵌入式語言，SQL語句能夠嵌入到高級語言程序中，供程序員設計程序時使用。而在兩種不同的使用方式下，SQL的語法結構基本上是一致的。這種以統一的語法結構提供兩種不同的操作方式，為用戶提供了極大的靈活性與方便性。
5、語言簡潔，易學易用
SQL功能極強，但由於設計巧妙，語言十分簡潔，完成數據定義、數據操縱、數據控制的核心功能只用了9個動詞：CREATE、 ALTER、DROP、 SELECT、 INSERT、 UPDATE、 DELETE、GRANT、 REVOKE。且SQL語言語法簡單，接近英語口語，因此容易學習，也容易使用。
B. 有專門的 plsql 程序員嗎前景如何啊想向資料庫方面發展啊
我是oracle得ocp，剛剛過的。現在在一個做erp的公司工作。總的來說，做這行會到處跑沒有固定地點，主要跟著項目走。要學的比較多，單純pl/sql是基礎。努力吧，現在來看工資不錯，但也很辛苦，直接和客戶打交道。
C. 為什麼很多程序員不願意寫sql
因為.net和sql
server都是微軟的產品，自家兄弟兼容性肯定較好。
D. 在php程序員里用面向對象寫sql語句好還面向過程好那個效率更快、速度更高
面向對象與面向過程在許多編程語言中只能使用二者之一來進行編程，但是PHP語言與其他編程語言有不同之處，那就是我們可以自由的選擇或者將如果你是剛接觸PHP，用PHP面向過程的風格來書寫代碼很可能是你唯一的選
面向對象與面向過程在許多編程語言中只能使用二者之一來進行編程，但是PHP語言與其他編程語言有不同之處，那就是我們可以自由的選擇或者將 如果你是剛接觸PHP，用PHP面向過程的風格來書寫代碼很可能是你唯一的選擇。但是如果你經常上PHP論壇和新聞組的話，你應該會看到有關「對象」的文章。你也可能看到過如何書寫面向對象的PHP代碼的教程。或者你也可能下載過一些現成的類庫，並嘗試著去實例化其中的對象和使用類方法--盡管你可能沒有真正理解這些類為什麼可以工作，或者為什麼需要使用PHP面向對象的方法來實現功能。
應該使用「面向對象」的風格還是「面向過程」的風格？雙方各有支持者。像「對象是低效的」或「對象非常棒」這樣的議論也時有耳聞。本文不嘗試輕易判定兩種方法的哪種具有絕對的優勢，而是要找出每種方法的優缺點。
以下是PHP面向過程風格的代碼示例：
<?php
print"Hello,world.";
?>
以下是PHP面向對象風格的代碼示例：
<?php
classhelloWorld{
functionmyPrint(){
print"Hello,world.";
}
}
$myHelloWorld=newhelloWorld();
$myHelloWorld->myPrint();
?>
如果你想了解一些「面向對象」的基本知識，請使用Google搜索，網路上有非常多精彩的文章。
誰像這樣寫代碼？
為了理解為什麼這個論題成為論壇上口水戰的導火線，我們看一些每個陣營的比較極端的例子。我們看看「過程狂熱」和「對象狂熱」。看看他們的觀點聽起來是不是有點熟悉。
過程狂熱
過程狂熱曾在上課時被計算機教師批評，因為這種方法沒有使用更加抽象的實現方式。而支持PHP面向過程者的觀點「它可以工作！」並不能提高其編程水平和檔次。畢業後他們可能找到一個工作，寫驅動程序，文件系統或其它的偏向底層的編程，他們的注意力集中於速度和代碼的精煉。
「過程狂熱」極端的例子是抵制對象，抵制抽象化。他們總在想著如何讓程序運行起來更快，而不在乎別人是否能讀懂他們的代碼。他們常常把編程當成競賽而不是團隊活動。除了PHP外，他們最喜愛的編程語言是C和匯編。在PHP世界中他們可能會開發PECL模塊，貢獻出高效率的代碼。
對象狂熱
對象狂熱者熱衷於在任何時候使用PHP面向對象的風格來書寫代碼。他們沒有真正考慮過用這種方式是否會影響程序的執行效率。有時候讓人覺得他們更享受抽象的設計概念而不是現實的代碼。他們通常很可能是項目管理者或文檔書寫者。
對象狂熱者指出，如果沒有抽象的設計方法我們仍然在使用0和1進行編程。他們喜歡用偽碼來描述問題。極端的例子是對象狂熱者即使知道有時候會犧牲效率仍然使用對象。除了PHP，他們最喜歡的語言是Java和Smalltalk。在PHP世界中，他們可能會開發PEAR模塊，貢獻文檔化非常好，易於維護的代碼。
不要偏激和諷刺
你知道為什麼論壇上總是充斥著各種偏見嗎？你的經驗閱歷，你對新事物的態度都可能是原因。作為程序員，我們需要時常注意這些偏見並以開放的心態去學習新事物。
你的編碼傾向？
考慮一下當你書寫PHP代碼時有什麼偏好或傾向。通常這些偏好是比較隱晦的。有時候你可能在每個項目中有著同樣的偏好。我個人傾向於「優雅」，但我不想在此定義如何才是「優雅」的代碼，那應當出現在另一篇文章里。但是，理論化的偏好不一定適合於實際項目—相反地，他們常常是一種偏見。
理論化的傾向
•用最少行數的代碼提供一個完整的解決方案
•在問題層次上考慮問題
這聽起來似乎很不錯。但「代碼行數最少」如何來衡量呢？要把代碼注釋算在內嗎？我們是否要把每一行都串起來而只用分號來區分呢？大括弧呢？很明顯這種想法是錯誤的。
再解釋一下什麼是「問題層次」。這是否意味著在我們的方案中的每個概念都需要建立一個類？或者需要在每個獨立的文件里保持問題的每個部分，並建立一個復雜的文件樹來與現實中的問題相對應？就是這樣的想法--為每個想法准備一個文件或類！
很明顯這些概括極端化後變得可笑。但現實中存在更微妙的證明。是否常常會有程序員在團隊合作時插入一行復雜的，強大的但沒有注釋的代碼？這對於接手維護這些代碼的人來說無疑是非常令人沮喪的事。相反地，是否你的官僚的自以為是的上一級程序員常常「橫沖直撞」般地，建立介面和類?而那些介面和類不僅僅限制了負責實現的程序員，也限制了效率和靈活性，導致客戶要求擴展程序時手足無措。這些都是以上各種傾向的微妙的證明。
實際傾向
一個項目開始的時候，首先要尋求實際的編碼目的和方向。這個項目的實現目標是什麼？下面是可能是答案。
•開發快，發布快
•盡可能快地運行
•易於維護，改進和擴展
•發布一個API
第一、二個方向傾向於使用過程化的風格，而最後兩個傾向於使用PHP面向對象的風格。
什麼時候某種方式更有效？
現在讓我們試著評價每種方式在現實中的優勢。
PHP面向過程案例
有關PHP的面向過程化編程優勢的一個基礎性的論據是：PHP是一個解釋性的語言--這意味著，不像其它的語言一樣，它不會被編譯成一個可執行的包，而是被解釋並馬上執行。它是一種腳本語言並存儲於文本文件中(例外的，如果使用了Zend編譯工具)。
另一個反對在PHP4及更低版本中使用面向對象方式進行編碼的理由是：在PHP的早期版本中對象的功能並沒有經過良好設計。就像Rasmus曾說過的：「那是事後才想起要增加的功能」。這意味著在PHP4及更早的版本中，對象的效率是個問題。但PHP5出來後，這種情形會有改觀。
以下兩個最流行的PHP程序--OsCommerce和PhpMyAdmin.主要使用面向過程的編碼方式。它們構建起來很快，運行起來也很快。兩者都很自然地採用嵌入HTML的方法。
OsCommerce
OsCommerce實際上使用了很多對象，但絕大部分功能是通過「過程」來實現的。我曾經hack過OsCommerce，為其增添一些對於客戶非常實用的自定義功能。這個過程是挺麻煩的，因為OsCommerce中的很多過程代碼，沒有使用模板化的系統，並且設計成多語言版，所以需要花一定的時間才能上手。但是它可以工作，事實上它已經很好地運行在數目眾多的電子商務站點上了。OsCommerce同時提供了一個論壇和一個開發框架用來開發模塊和插件。因此，現在已經有了很多其它開發者提供的實用的功能模塊。
PhpMyAdmin
PhpMyAdmin直接使用的類只有一個：MimerSQLValidator類，依賴於PEAR包中的Mail_Mime,Net_DIME和SOAP。這可能是考慮到開發的方便：利用現成的可以實現目的的代碼。除此之外，一切都是面向過程的，HTML和PHP代碼也是混雜在一起。
PhpMyAdmin是我幾乎每天都要用到的一個工具，用來對少量的數據表進行不太復雜的處理。有時我甚至鼓勵我的客戶將它當作後端的管理工具來使用（當然我會限制他們的許可權）。PhpMyAdmin的表現非常棒，也很快。有時我想在一些項目中擴展PhpMyAdmin作為後端的管理工具，利用它的一些新功能如數據查詢語句書簽可以很方便地展示給我的客戶和編輯。隨著每個新版本的推出，PhpMyAdmin越來越實用，功能越來越強大。 軟體開發網
PHP面向過程小結
以上兩個使用面向過程風格的程序都有非常好的文檔和代碼注釋。OsCommerce提供的開發框架可以增加維護性和擴展性。但是兩者都沒有提供API，不能擴展程序到另外的體系中。
如果你想把OsCommerce整合到一個帳單程序中，需要花費大量的時間和精力，就像擴展PhpMyAdmin成一個供客戶使用的後端管理工具。不過從它們設計的目的來看，確實在各自的領域中都表現地很出色。
PHP面向對象案例
支持面向對象風格者的觀點都集中於擴展性和封裝。僅僅用面向對象的方式來寫代碼不會為你的代碼產生文檔，但它可以鼓勵你為之添加文檔。並且，為了易於擴展，你可能會寫一個API。PHP5許諾讓面向對象編程更加愉快。我開玩笑地將它稱為PHP中的」Java2」版本，因為它整合了Java中的許多特性，像介面，面向對象模型，try-catch語句等。但即使在對面向對象支持不
力的PHP4中，仍然出現了許多出色的面向對象應用程序。
Smarty
Smarty用來構建帶有復雜表單並基於模板的站點。最近，我寫了一個可以完全換「皮膚」的在線考試系統—可以不用改變任何底層的代碼和功能就可以將整個站點的外觀界面和風格完全改變。為了讓設計師可以易於設計新的界面，我設計了一個自定義的標簽庫作為Smarty標簽庫的擴展。可以像這樣簡單地插入：
["|"]
在一個頁面的頂端有分隔開的導航。因為Smarty已經提供了非常強大的機制來表現變數中包含的數據，這是一個映射較復雜的Smarty標簽到skin標簽的簡單過程。
由於Smarty封裝成一個類，並且它的方法都有很詳盡的文檔，使得使用模板的過程變得令人難以置信地易於擴展。同時，通過強制性地只能顯式地傳遞你要使用的變數給Smarty模板的方法，Smarty也為PHP的環境變數提供了一個保護層。這種方法有助於在Smarty模板設計師和程序員間建立安全、可靠的工作關系。
FPDF
FPDF是一個非常優秀的工具。如果你被改來改去的pdflib的API所困惑，或者不願為商業化的解決方案而交錢；或者由於共享主機的限制，無法使用擴展模塊—請考慮使用這個免費的，純PHP構建的PDF生成工具。
這個類有很好的文檔，包括許多很好的例子來闡述如何在PDF中布局文本和圖片。在上面提到的同一個在線學習站點我使用FPDF來動態生成PDF文件，使用truetype字體和300dpi精度的圖像。在PHP中實例化FPDF類並進行PDF操作並不會花費太多額外的時間，因為PDF本身就可能需要花費幾分鍾來下載。事實上，動態生成並傳送一個PDF所花的時間不比當使用一個慢速的網路連接來傳送靜態PDF文件所花的時間多。這都是相對而言的。並且，由於FPDF是基於類的，他可以被擴展。事實上，有些類方法雖然存在但還沒有完全實現，僅作為一個框架，這可以為你在子類中建立你自己的內容(如自定義的頭尾元素)提供向導。
PHP面向對象小結
Smarty和FPDF都提供了帶有良好文檔的API來擴展主類。這說明了在類的內部組織方法和數據的必要性--有時同樣的功能可以用函數和全局變數來完成，但這樣不易於擴展。並且，使用對象對跟蹤和保持PDF或HTML文檔的風格非常有幫助，你可以將同樣的數據用不同的格式來發布。Smarty和FPDF都是使用對象來建立靈活實用的類庫的極好的例子。
為什麼兩種方式都是必需的？
回到我們充滿熱情的程序員身上，我們開始贊美他們：
•我們欣賞Smarty和FPDF的實用性和擴展性
•我們欣賞osCommerce和phpMyAdmin的運行速度和良好表現
這種欣賞還包括對PHP的一些基礎開發。PECL和PEAR都收到了很多贊揚和批評。我想這兩個項目為闡明PHP面向過程和面向對象編程的區別提供了很好的例子。
PECl提供了PHP的擴展庫，用C和面向過程的方式開發，注重速度和簡潔精煉。通常，這些都是從已經存在的LGPL軟體中移植而來，其中許多有趣的特性已經加入PHP。畢竟，PHP是用C寫的。
PEAR則貢獻了很多有趣的類如建立Excel表或改變DNS記錄等。使用PEAR類庫可以為你節約大量時間，甚至可以讓你在不怎麼熟悉PHP的情況進行開發—「我不理解但它能用！」。
總結
希望本文能加深你對PHP面向對象和PHP面向過程的兩種編程方式的理解，並且更重要地—鼓勵你在更具體的細節上進行探索。我希望你會有自己的想法，並在實際開發中檢驗你的項目開發傾向，總結出更多實際的案例，並不嗇寫些針對本文的評論。
總之，每種方式都有其優勢的一面，糾纏於爭論不如離開去寫些實際的代碼！
E. 寫sql的不算是程序員嗎，為什麼都把兩者分開說
程序員顧名思義需要跟「程序」打交道，程序是啥？？目前軟體行業裡面指編程語言，C，C++，JAVA等等，這些是編程語言。而SQL呢？？？SQL本身也是編程語言，而你說的「寫SQL」就不一定了，如果只是寫SQL查詢查詢數據，那充其量就是寫SQL語句而已。執行一個select得到一個結果。沒有業務，沒有邏輯，所以可能不算。
F. sql 腳本程序員主要做什麼，這腳本是否和我們資料庫使用到的語法是否會相同
對於資料庫所要使用語句，主要是三種
1.基本sql語句，就是建表，查詢，登錄，更新，刪除等
2.程序語句，就是存儲過程，函數等使用的語句
3.命令語句，就是在命令行模式下的語句，比如導入導出文件/數據，增加修改用戶，許可權等等的語句
腳本程序員要做什麼，這個要看項目情況而言。一般情況下，使用比較多的是基本sql語句和命令語句（有些項目裡面程序語句也會使用到的），就是把創建和修改資料庫對象等很多動作行為做成腳本（可以理解成批處理文件），然後需要的時候調用執行腳本就可以了，不需要我們再去手動寫代碼。
G. SQL是個大學的專業嗎哪是個什麼專業
如果你正在負責一個基於SQL Server的項目，或者你剛剛接觸SQL Server，你都有可能要面臨一些資料庫性能的問題，這篇文章會為你提供一些有用的指導（其中大多數也可以用於其它的DBMS）。
在這里，我不打算介紹使用SQL Server的竅門，也不能提供一個包治百病的方案，我所做的是總結一些經驗----關於如何形成一個好的設計。這些經驗來自我過去幾年中經受的教訓，一直來，我看到許多同樣的設計錯誤被一次又一次的重復。
你了解你用的工具嗎？
不要輕視這一點，這是我在這篇文章中講述的最關鍵的一條。也許你也看到有很多的SQL Server程序員沒有掌握全部的T-SQL命令和SQL Server提供的那些有用的工具。
「什麼？我要浪費一個月的時間來學習那些我永遠也不會用到的SQL命令？？？」，你也許會這樣說。對的，你不需要這樣做。但是你應該用一個周末瀏覽所有的T-SQL命令。在這里，你的任務是了解，將來，當你設計一個查詢時，你會記起來：「對了，這里有一個命令可以完全實現我需要的功能」，於是，到MSDN查看這個命令的確切語法。
不要使用游標
讓我再重復一遍：不要使用游標。如果你想破壞整個系統的性能的話，它們倒是你最有效的首選辦法。大多數的初學者都使用游標，而沒有意識到它們對性能造成的影響。它們佔用內存，還用它們那些不可思議的方式鎖定表，另外，它們簡直就像蝸牛。而最糟糕的是，它們可以使你的DBA所能做的一切性能優化等於沒做。不知你是否知道每執行一次FETCH就等於執行一次SELECT命令？這意味著如果你的游標有10000條記錄，它將執行10000次SELECT！如果你使用一組SELECT、UPDATE或者DELETE來完成相應的工作，那將有效率的多。
初學者一般認為使用游標是一種比較熟悉和舒適的編程方式，可很不幸，這會導致糟糕的性能。顯然，SQL的總體目的是你要實現什麼，而不是怎樣實現。
我曾經用T-SQL重寫了一個基於游標的存儲過程，那個表只有100,000條記錄，原來的存儲過程用了40分鍾才執行完畢，而新的存儲過程只用了10秒鍾。在這里，我想你應該可以看到一個不稱職的程序員究竟在幹了什麼！！！
我們可以寫一個小程序來取得和處理數據並且更新資料庫，這樣做有時會更有效。記住：對於循環，T-SQL無能為力。
我再重新提醒一下：使用游標沒有好處。除了DBA的工作外，我從來沒有看到過使用游標可以有效的完成任何工作。
規范化你的數據表
為什麼不規范化資料庫？大概有兩個借口：出於性能的考慮和純粹因為懶惰。至於第二點，你遲早得為此付出代價。而關於性能的問題，你不需要優化根本就不慢的東西。我經常看到一些程序員「反規范化」資料庫，他們的理由是「原來的設計太慢了」，可結果卻常常是他們讓系統更慢了。DBMS被設計用來處理規范資料庫的，因此，記住：按照規范化的要求設計資料庫。
不要使用SELECT *
這點不太容易做到，我太了解了，因為我自己就經常這樣干。可是，如果在SELECT中指定你所需要的列，那將會帶來以下的好處：
1 減少內存耗費和網路的帶寬
2 你可以得到更安全的設計
3 給查詢優化器機會從索引讀取所有需要的列
了解你將要對數據進行的操作
為你的資料庫創建一個健壯的索引，那可是功德一件。可要做到這一點簡直就是一門藝術。每當你為一個表添加一個索引，SELECT會更快了，可INSERT和DELETE卻大大的變慢了，因為創建了維護索引需要許多額外的工作。顯然，這里問題的關鍵是：你要對這張表進行什麼樣的操作。這個問題不太好把握，特別是涉及DELETE和UPDATE時，因為這些語句經常在WHERE部分包含SELECT命令。
不要給「性別」列創建索引
首先，我們必須了解索引是如何加速對表的訪問的。你可以將索引理解為基於一定的標准上對表進行劃分的一種方式。如果你給類似於「性別」這樣的列創建了一個索引，你僅僅是將表劃分為兩部分：男和女。你在處理一個有1,000,000條記錄的表，這樣的劃分有什麼意義？記住：維護索引是比較費時的。當你設計索引時，請遵循這樣的規則：根據列可能包含不同內容的數目從多到少排列，比如：姓名+省份+性別。
使用事務
請使用事務，特別是當查詢比較耗時。如果系統出現問題，這樣做會救你一命的。一般有些經驗的程序員都有體會-----你經常會碰到一些不可預料的情況會導致存儲過程崩潰。
小心死鎖
按照一定的次序來訪問你的表。如果你先鎖住表A，再鎖住表B，那麼在所有的存儲過程中都要按照這個順序來鎖定它們。如果你（不經意的）某個存儲過程中先鎖定表B，再鎖定表A，這可能就會導致一個死鎖。如果鎖定順序沒有被預先詳細的設計好，死鎖是不太容易被發現的。
不要打開大的數據集
在CSDN技術論壇中 :），一個經常被提出的問題是：我怎樣才能迅速的將100000條記錄添加到ComboBox中？這是不對的，你不能也不需要這樣做。很簡單，你的用戶要瀏覽100000條記錄才能找到需要的記錄，他一定會詛咒你的。在這里，你需要的是一個更好的UI，你需要為你的用戶顯示不超過100或200條記錄。
不要使用伺服器端游標
與伺服器端游標比起來，客戶端游標可以減少伺服器和網路的系統開銷，並且還減少鎖定時間。
使用參數查詢
有時，我在CSDN技術論壇看到類似這樣的問題：「SELECT * FROM a WHERE a.id='A'B，因為單引號查詢發生異常，我該怎麼辦？」，而普遍的回答是：用兩個單引號代替單引號。這是錯誤的。這樣治標不治本，因為你還會在其他一些字元上遇到這樣的問題，更何況這樣會導致嚴重的bug，除此以外，這樣做還會使SQL Server的緩沖系統無法發揮應有的作用。使用參數查詢， 釜底抽薪，這些問題統統不存在了。
在程序編碼時使用大數據量的資料庫
程序員在開發中使用的測試資料庫一般數據量都不大，可經常的是最終用戶的數據量都很大。我們通常的做法是不對的，原因很簡單：現在硬碟不是很貴，可為什麼性能問題卻要等到已經無可挽回的時候才被注意呢？
不要使用INSERT導入大批的數據
請不要這樣做，除非那是必須的。使用UTS或者BCP，這樣你可以一舉而兼得靈活性和速度。
注意超時問題
查詢資料庫時，一般資料庫的預設都比較小，比如15秒或者30秒。而有些查詢運行時間要比這長，特別是當資料庫的數據量不斷變大時。
不要忽略同時修改同一記錄的問題
有時候，兩個用戶會同時修改同一記錄，這樣，後一個修改者修改了前一個修改者的操作，某些更新就會丟失。處理這種情況不是很難：創建一個timestamp欄位，在寫入前檢查它，如果允許，就合並修改，如果存在沖突，提示用戶。
在細節表中插入紀錄時，不要在主表執行SELECT MAX(ID)
這是一個普遍的錯誤，當兩個用戶在同一時間插入數據時，這會導致錯誤。你可以使用SCOPE_IDENTITY，IDENT_CURRENT和@@IDENTITY。如果可能，不要使用@@IDENTITY，因為在有觸發器的情況下，它會引起一些問題（詳見這里的討論）。
避免將列設為NULLable
如果可能的話，你應該避免將列設為NULLable。系統會為NULLable列的每一行分配一個額外的位元組，查詢時會帶來更多的系統開銷。另外，將列設為NULLable使編碼變得復雜，因為每一次訪問這些列時都必須先進行檢查。
我並不是說NULLS是麻煩的根源，盡管有些人這樣認為。我認為如果你的業務規則中允許「空數據」，那麼，將列設為NULLable有時會發揮很好的作用，但是，如果在類似下面的情況中使用NULLable，那簡直就是自討苦吃。
CustomerName1
CustomerAddress1
CustomerEmail1
CustomerName2
CustomerAddress2
CustomerEmail3
CustomerName1
CustomerAddress2
CustomerEmail3
如果出現這種情況，你需要規范化你的表了。
盡量不要使用TEXT數據類型
除非你使用TEXT處理一個很大的數據，否則不要使用它。因為它不易於查詢，速度慢，用的不好還會浪費大量的空間。一般的，VARCHAR可以更好的處理你的數據。
盡量不要使用臨時表
盡量不要使用臨時表，除非你必須這樣做。一般使用子查詢可以代替臨時表。使用臨時表會帶來系統開銷，如果你是用COM+進行編程，它還會給你帶來很大的麻煩，因為COM+使用資料庫連接池而臨時表卻自始至終都存在。SQL Server提供了一些替代方案，比如Table數據類型。
學會分析查詢
SQL Server查詢分析器是你的好夥伴，通過它你可以了解查詢和索引是如何影響性能的。
使用參照完整性
定義主健、唯一性約束和外鍵，這樣做可以節約大量的時間。
H. 有一位程序員說我的SQL語句 沒事用 inner join 和 left join 說我的SQL語句臟亂差...
這東西沒有絕對，看效率和業務需要，另外可以看看資料庫執行計劃。
I. 想要自己做一個小型的erp，懂點sql,對硬體操作系統之類的比較熟，目前
我是做java企業級開發的，就算是找到一個開源的完整erp做修改，也得需要學完javase基礎以及部分框架，要不然你不會修改的，vb是可視化編程，比較簡單，具體沒用過，這個沒法評論