小伙想入IT行業，資料庫的確是個不錯的切入口。
sql server的資料庫在資料庫行業，是比較低端的資料庫，和ORACLE DB2 SYBASE等都還有很大的差距，不過既然是初學，這是一個比較簡單的資料庫，有所有關系資料庫的功能。
將來再去學習ORACLE 什麼的，考個ORACLE的認證（好幾萬塊），那時就恭喜你真正進入了IT行業鳥……
② SQL資料庫的應用領域、現狀、發展前景
SQL資料庫是具有數據操縱和數據定義等多種功能的資料庫語言，這種語言具有交互性特點，能為用戶提供極大的便利，資料庫管理系統應充分利用SQL語言提高計算機應用系統的工作質量與效率。
一、SQL資料庫的應用領域
1、多媒體資料庫
這種資料庫主要存儲與多媒體有關的數據，如語音、圖像和視頻數據。多媒體數據最大的特點是數據連續、數據量大、存儲空間大。
2、移動資料庫
這種資料庫是在筆記本電腦、掌上電腦等移動計算機系統上開發的。資料庫的最大特點是通過無線數字通信網路傳輸。移動資料庫可以隨時隨地獲取和訪問數據，為一些業務應用和一些突發事件帶來了極大的便利。
3、空間資料庫
目前，這種資料庫發展迅速。它主要包括地理信息資料庫（也稱為GIS）和計算機輔助設計（CAD）資料庫。其中，地理信息資料庫一般存儲與地圖相關的信息數據；CAD資料庫一般存儲機械、集成電路、電子設備設計圖紙等設計信息的空間資料庫。
4、信息檢索系統
信息檢索是根據用戶輸入的信息從資料庫中查找相關文檔或信息，並將信息反饋給用戶。信息檢索領域與資料庫領域同步發展。它是一個典型的聯機文檔管理系統或聯機圖書目錄。
5、分布式信息檢索
這種資料庫是隨著Internet的發展而產生的。它廣泛應用於Internet和遠程計算機網路系統中。特別是隨著電子商務的發展，這種資料庫的發展更為迅速。許多網路用戶（如個人、公司或企業等）將信息存儲在自己的計算機中。
6、專家決策系統
專家決策系統也是資料庫應用的一部分。因為越來越多的數據可以在網上獲得，特別是通過這些數據，企業可以對企業的發展做出更好的決策，從而使企業能夠更好地經營。隨著人工智慧的發展，專家決策系統的應用越來越廣泛。
二、SQL資料庫現狀
1、自主研發
國內自主研發關系型資料庫的企業、單位基本上都是發源於上世紀90年代的，而且都是以大學、科研機構為主。到今天，有代表性的廠商有：達夢–由華中理工馮玉才教授創辦，完全自主研發。以Oracle為參照、追趕對象。
2、引進源代碼
引進資料庫源代碼發展國產資料庫，如今，經濟發展，而且IBM也願意迎合國人對於國產化的訴求，將擱置多年的Informix源代碼拿出來，發揮余熱。2015年以來，與IBM簽訂源代碼授權的公司有華勝天成、南大通用（Gbase8t）和星瑞格。這三個公司成為以引進Informix源代碼發展國產資料庫的代表。
三、SQL資料庫發展前景
1、產品形成系列化
一方面，Web和數據倉庫等應用的興起，數據的絕對量在以驚人的速度迅速膨脹；另一方面，移動和嵌入式應用快速增長。針對市場的不同需求，資料庫正在朝系列化方向發展。
2、智能化集成化
SQL資料庫技術的廣泛使用為企業和組織收集並積累了大量的數據。數據豐富知識貧乏的現實直接導致了聯機分析處理（OLAP）和數據挖掘（DataMining）等技術的出現，促使資料庫向智能化方向發展。
3、支持各種互聯網應用
SQL資料庫管理系統是網路經濟的重要基礎設施之一。支持Internet（甚至於MobileInternet）資料庫應用已經成為資料庫系統的重要方面。例如，Oracle公司從8版起全面支持互聯網應用，是互聯網資料庫的代表。
(2)sql資料庫發展方向擴展閱讀：
SQL包括了所有對資料庫的操作，主要是由4個部分組成：
1、數據定義：又稱為「DDL語言」，定義資料庫的邏輯結構，包括定義資料庫、基本表、視圖和索引4部分。
2、數據操縱：又稱為「DML語言」，包括插入、刪除和更新三種操作。
3、數據查詢：又稱為「DQL語言」，包括數據查詢操作。
4、數據控制：又稱為「DCL語言」，對用戶訪問數據的控制有基本表和視圖的授權及回收。
5、事務控制：又稱為「TCL語言」，包括事務的提交與回滾。
參考資料來源：網路-SQL資料庫
③ 《資料庫原理》知識點之SQL概述
3.1.1 SQL發展歷程
考核要求：達到「識記」
層次知識點：SQL的發展歷程
SQL：結構式查詢語閉顫言，雖然名為查詢語言，實際上具有定義、查詢、更新和控制等多種功能。
3.1.2 SQL數據慧態核庫的體系結構
考核要求：達到「領會」
層次知識點：三級結構的理解
SQL資料庫的體系結構也是三級結構，但術語與傳統關系模型術語不同，在SQL中，關系模式稱為「基本表」，存儲模式稱為「存儲文件」，子模式稱為「視圖」，元組稱「行」，屬性稱「列」。
SQL資料庫體系的結構要點如下：
（1）一個SQL資料庫是表的匯集。
（2）一個SQL表由行集構成，行是列的序列，每列對應一個數據項。
（3）表或者是基本表，或者是視圖。基本表是實際存儲在資料庫中的表，視圖由是由若干基本表或其他視圖構成的表的定義。
（4）一個基本表可以跨一個或多個存儲文件，一個存儲文件也可存放一個或多個基本表。存儲文件與物理文件對應。
（5）用戶可以用SQL語句對表進行操作，包括視圖和基本表。
（6）SQL的用戶可以是應用程序，也可以是終端用戶。
3.1.3 SQL的組成
考核要求：達到「識記」
層次知識點：四個組成部分
SQL由四部分組成：
（1）數據定義：SQL DDL.定義SQL模式，基本表、視圖和索引。
（2）數據操縱：SQL DML.包括數據查詢和數據更新（增、刪、改）。
（3）數據控制：包括對基本表和視圖的授權、完整性規則的描述，事務控制等前掘。
（4）嵌入式SQL的使用規定。
④ 學sql資料庫可以干什麼除了學這還要學什麼
學sql資料庫可以開發系統、軟體、做網站。具體是你想做什麼類！給自己找個定位，然後朝那個方向發展。你的資料庫學好了，可以選擇編程語言C++、java、asp、asp.net等，和sql資料庫合用開發軟體、系統。如果你是初學者，我建議，你要學語言了，不一定什麼流行就學什麼，還是從最基本
的學起，可以從c語言學起，打好基礎，以後再學別的語言也不難，因為雖然有這么多編程語言，只要能夠精通一、兩種語言就行了。
⑤ NewSQL分布式資料庫發展策略討論
作者 石默研
本文對新一代NewSQL分布式資料庫發展策略中的普遍困擾進行討論，包括雲原生（Cloud Native）與本地部署(On Premise)、HTAP進展方向、分布式與單機需求等分布式資料庫商業與技術發展中難以決策的問題。
1. 困擾
分布式NewSQL資料庫近年來蓬勃興起，其原因顯而易見：切中了業務與數據量不斷增長的用戶對關系型資料庫RDBMS需求，這在傳統RDBMS到大數據的發展階段中，有相當一段時間是空白。同時，隨著互聯網技術的不斷發展與普及，用雲計算模式滿足IT需求似乎已經成為未來 社會 產業互聯網發展的明確趨勢，也就是說，有一種共識：不久的將來，絕大多數產業的IT服務是從公共的、行業的或者私有的、混合的雲計算中心提供的。這一共識又帶來了雲原生（Cloud Native）概念與技術的興起，而分布式NewSQL資料庫自然也應該是雲原生的，這決定了其相當多的產品設計決策應以符合這一趨勢為原則。然而，在當今的現實中，滿足業務與數據量不斷增長的RDBMS需求的用戶，與雲原生的用戶，除了互聯網企業外，大多數情況下，並不重合，需要On-Premise部署的用戶仍然佔有很大比重，這就帶來了第一個困擾：雲原生（Cloud Native）與本地部署(On Premise)對產品發展要求的矛盾。
另一個困擾，是關於HTAP，即交易與分析混合負載。HTAP是當今非常火的一個概念與技術，在交易庫上直接進行分析，而不再是將「數據從交易庫搬下來，挪到另一個資料庫中去」這樣的繁瑣過程。可以毫不誇張的說： 歷史 上規模性企業IT復雜度的相當一部分，都來自於「搬數據」，這導致了數據採集、實時採集、全增量合並、數據傳輸、數據載入、數據建模、數據質量、數據標准、企業級元數據管理等繁雜多樣的技術環節的產生，導致了企業數據分布、數據流向、數據模型、主數據、基礎數據平台、ODS/數據倉庫/數據集市、數據治理等復雜的數據架構設計優化領域，導致了由於多系統大規模數據搬遷而帶來的如數據交換平台之類的復雜調度工程......。咋眼一看，感覺該企業的數據技術好厲害，相關各領域的技術產品好豐富，技術人員的相關技能也好受歡迎。但如果在交易庫就能直接滿足分析需求而不影響生產效能的話，這些復雜高級的技術環節不都成了「自己給自己造了一座山，還說自己爬的好辛苦」？然而，現實卻是，問題並不這么簡單，除了在交易庫中進行分析會影響業務效能外，還有很多原因導致這一現象產生：交易庫並不需要存儲那麼長的 歷史 數據，而分析往往是需要建立在大量 歷史 數據之上的；交易庫的模型往往並不適合分析需求，多數情況下需要重要建模，如非常流行且價值不菲的各行業數倉主題模型；用於交易的OLTP資料庫與用於分析的OLAP資料庫，其技術體系完全不同；以及大型企業已固化的內部業務結構並沒有留給交易/分析整合可實施的可行空間......等等。由於， 歷史 積累的企業級數據體系相當復雜，HTAP的發明者迄今為止都沒有系統表達完全替代數據分析需求、自頂而下重構企業數據體系的架構級策略，而是將產品重點定位在技術優化層面：在交易庫上直接完成實時統計分析，滿足高並發需求且不影響業務效能；或者是為實時分析統計/查詢而建設的數據服務中間平台。然而，即使是暫時沒有這種策略性的意向，在面向AP的產品具體研發中，又會發現明確的界限確實不好把握，隨著一個個具體功能的不斷完善，似乎假以時日，技術上也不是沒有完全替代純OLAP平台的可能性。那麼，HTAP究竟如何定位呢？
再者就是規模化的分布式需求，與小規模的單機資料庫需求（這里指邏輯上的單機）之間的矛盾：分布式資料庫，自然而然是要應對規模化的數據管理需求的，長尾的小規模需求當然不應在產品設計考慮之列，同時，大炮轟蒼蠅經常還打不好；然而，分布式NewSQL資料庫又應該是雲原生的，如果把雲原生的業務含義理解為「全自助」，它應該以支持什麼樣的需求為主呢？現實看來，小規模長尾業務對雲原生資料庫的需求最起碼應該是占據相當大的比重的。顯而易見，如果是大規模的數據管理需求，即使是部署在雲上，DBPaaS的「全自助」是其核心需求嗎？這種規模化的業務，如果是雲上的On-Premise又需要做出哪些方面的改變？從互聯網與雲計算發展的 歷史 來看，「雲自助」，其最核心的商業動機當然包括給用戶側的運維帶來了方便，但更重要的可能是給雲服務運營商應對海量長尾客戶的安裝與運維帶來了極大的成本優勢。這正如銀行的小微及個人消費貸款都要走互聯網線上模式，而重客、大客甚至中小企業信貸仍然是以線下為主的策略一樣，本質是成本問題，而不是客戶方便性問題。於是，矛盾顯而易見：分布式是面向規模客戶的，起碼是中、大型客戶，而雲原生卻有可能、最起碼相當一段時間內是要以長尾客戶為主要服務對象的。
以上困擾實質上，都涉及到了NewSQL分布式資料庫的產品發展策略問題。
2. 討論
問題是客觀而又普遍的，但分析與應對策略往往包含主觀因素：人們的一個決定與決策，很多情況下並不由嚴格推理而來，而是心中已經有一個答案，再來找理由支持它。這里的討論或許也並不能例外。
首先，來看看Cloud Native與On Premise。雲原生本應是資料庫即服務，然而目前真正有規模化數據增長需求的NewSQL應用相當多的情況下卻是付費On Premise與免費On Premise區別，很多互聯網企業的應用也可能只是部署在雲基礎設施上而已，真正的雲原生更多是一些實驗性、嘗試性的需求。但雲原生資料庫在公有雲、行業雲以及大型私有雲上已經逐漸在形成一種意識上的共識，其商業前景不可限量。也就是說，未來的數字化轉型進程中，產業互聯網的資料庫部署，會逐漸向雲基礎設施遷移，長在雲上。它可能是公有雲，也可能是行業雲，也可能是私有雲，它們都是被定義為雲原生NewSQL資料庫的市場范圍。當然，肯定還會有相當一部分資料庫長在雲下，這也不用糾結，將其排除在雲原生市場戰略目標之外即可，就是說，不需要考慮這部分客戶需求對產品規劃的影響，因為前一部分的份額已經足夠大了。這樣看來，以雲原生為目標進行產品規劃的邏輯沒有問題，不過，還是要明確一點：長在雲上的資料庫是不是一定符合我們對「雲原生」的既有理解？這里認為，即使未來，在雲上形成了產業互聯網資料庫市場的主體，需要「全自助」的資料庫即服務可能也是以面向長尾客戶最為迫切、必不可少並且是核心本質，而對中大型以上的需求，「全自助」的意義相對有限，同時比較而言商業模式的轉變或者更關鍵些。那麼，如果是以「長在雲上」為市場目標，似乎可以將其定義為「廣義的雲原生」，同時，只要是「長在雲上」，那麼「雲原生」概念中高彈性、高可用、低成本、快速迭代、存算分離等技術優勢也都能方便獲得。而對「雲原生」策略中「雲原生」一詞的理解不同，對產品規劃決策的影響也應該有所不同：一是目前被認為是On Premise的客戶需求，或許也就是未來「雲原生」主體市場的需求；二是NewSQL資料庫關於雲原生服務的產品策劃，對用戶側「自助」水平的決策或許可以更靈活實用。高水平自助確實可以減輕客戶對IT的依賴程度，但這里認為，雲原生與用戶自行在雲上購買資源進行On-Premise部署相比，最關鍵的價值在於商業模式的改變，能自助多少，不一定是最重要的，因為成為雲服務商後，運營運維的工作只會更多，責任可能會更大，甚至有時連IaaS的運維也需要PaaS服務商兜底。但從一個個客戶的本地服務，變成集中化雲服務，就已經是本質性的模式轉變了。總之，需要就事論事，回到原點，仔細分析後決策，而不是用概念教條的判斷，因為概念本身的定義並不見得准確對應實際的業務需求。
再來看看HTAP，對這個問題，正如在其它文章中表達過的一樣，本文的觀點較為明確。一是隨著計算能力與架構的升級，從技術上講，AP與TP的界限會越來越模糊；另外特別是在雲原生的新世界裡，資料庫的這一特性又猶為重要，因為雲原生的重要作用之一就是要讓客戶盡量擺脫對IT運維的依賴，將越來越多的精力集中到自己的業務發展上來；同時端到端的能力提升對雲原生商業模式的貫徹也至關重要（需要仔細分析下目前DBPaaS的技術要求是否完全符合這一原點的、本質性的動力），過去與純OLAP資料庫的優勢比較糾結在這里也可以得到正面支持；再者，既然架構上已經走向了AP，就很難做到在產品規劃上時刻釐清純AP與混合負載的需求後，再將前者排除在外。於是，以「混合負載滿足部分AP需求」應該是由於投入與階段性市場策略導致的階段性產品規劃，而長遠來講，以一套技術架構滿足大多數需求，應該是雲原生NewSQL資料庫的追求。
接下來，就是關於規模化分布式與小規模單機需求的矛盾了。現在看來，經過上面的討論，這一點已經不是什麼問題了：因為「長在雲上」、從分散服務向集中服務的商業模式轉變就是指廣義的雲原生，而不一定要以小微的、迫切需要全自助的長尾為主流，那麼，雲原生NewSQL資料庫仍然應以規模化分布式為其主體的需求方向，而小規模單機則暫時可以不做為重點來考慮。
最後指出一點，希望也能引發進一步的思考：我們所批判的主機，也聲稱自己是分布式架構，暫且不論其是否客觀，但在現實中主機需要被替代的核心問題並不是有沒有分布式，而是：一、擴展不靈活帶來成本問題：「我只需要擴展一個節點，你卻讓我再買一台主機」；二、不自主可控；三、往往是軟硬體結合的設計策略，包括內存、網路、存儲與IO上的軟硬融合設計，而這一點，是否需要雲原生資料庫從廣義的定義出發進行學習參考，也是需要進一步討論的。
⑥ 學習SQL資料庫有前途嗎
sql算是中等的資料庫,也是基礎,學通了sql後其他的資料庫也很容易通,前途是很好,具體工資要看你掌握的程度了,精通的話,10萬20萬很正常.