sql業務
㈠ sql是干什麼用的用的哪些方面
SQL可以有兩個解釋：
一個是微軟的SQL Server，是一個大型的資料庫系統軟體，專門用於大批量的數據存儲和管理。
另一個解釋是Structured Query Language（結構化查詢語言）的縮寫，它是目前使用最廣泛的資料庫語言，SQL是由IBM發展起來的，後來被許多資料庫軟體公司接受而成為了業內的一個標准。就象SQL的名字一樣，我們可以通過容易理解的查詢語言，來和資料庫打交道，從資料庫中得到我們想要的數據。
對於SQL語言，有兩個組成部分： DML（data manipulation language）：它們是SELECT、UPDATE、INSERT、DELETE，就象它的名字一樣，這4條命令是用來對資料庫里的數據進行操作的語言。 DDL（data definition language）：DDL比DML要多，主要的命令有CREATE、ALTER、DROP等，DDL主要是用在定義或改變表（TABLE）的結構，數據類型，表之間的鏈接和約束等初始化工作上，他們大多在建立表時使用。
㈡ 我有兩個業務，是寫在一個SQL中還是寫兩個SQL處理
不同業務最好分開，便於以後功能拓展，如果寫在一起，其中一個業務需求變化了，
你改這個sql就會影響到另一個業務。如非必要，盡量保持表、業務的原子性，交叉太多，隨著後續工作和邏輯遞增你會瘋掉的。
我幫樓主找了點關於《設計原則》的資料，看看能否對有點啟發（非資料庫方面的）
7種設計壞味道 1.僵化性： 很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其它改動。
2.脆弱性： 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。
3.牢固性： 很難解開系統的糾結，使之成為一些可在其他系統中重用的組件。
4.粘滯性： 做正確的事情比做錯誤的事情要困難。
5.復雜性(不必要的)： 設計中包含有不具任何直接好處的基礎結構。
6.重復性(不必要的)： 設計中包含有重復的結構，而該重復的結構本可以使用單一的抽象進行統一。 7.晦澀性： 很難閱讀、理解。沒有很好地表現出意圖。
11種原則 - Principle
----類原則
1.單一職責原則 - Single Responsibility Principle(SRP)
就一個類而言，應該僅有一個引起它變化的原因。
(職責即為「變化的原因」。)
2.開放-封閉原則 - Open Close Principle(OCP)
軟體實體（類、模塊、函數等）應該是可以擴展的，但是不可修改。
(對於擴展是開放的,對於更改是封閉的.
關鍵是抽象.將一個功能的通用部分和實現細節部分清晰的分離開來.
開發人員應該僅僅對程序中呈現出頻繁變化的那些部分作出抽象.
拒絕不成熟的抽象和抽象本身一樣重要. )
3.里氏替換原則 - Liskov Substitution Principle(LSP)
子類型(subclass)必須能夠替換掉它們的基類型(superclass)。
4.依賴倒置原則(IoCP) 或 依賴注入原則 - Dependence Inversion Principle(DIP)
抽象不應該依賴於細節。細節應該依賴於抽象。
(Hollywood原則: "Don't call us, we'll call you".
程序中所有的依賴關系都應該終止於抽象類和介面。
針對介面而非實現編程。
任何變數都不應該持有一個指向具體類的指針或引用。
任何類都不應該從具體類派生。
任何方法都不應該覆寫他的任何基類中的已經實現了的方法。)
5.介面隔離原則(ISP)
不應該強迫客戶依賴於它們不用的方法。
介面屬於客戶，不屬於它所在的類層次結構。
(多個面向特定用戶的介面勝於一個通用介面。)
----包內聚原則
6.重用發布等價原則(REP)
重用的粒度就是發布的粒度。
7.共同封閉原則(CCP)
包中的所有類對於同一類性質的變化應該是共同封閉的。
一個變化若對一個包產生影響，
則將對該包中的所有類產生影響，
而對於其他的包不造成任何影響。
8.共同重用原則(CRP)
一個包中的所有類應該是共同重用的。
如果重用了包中的一個類，
那麼就要重用包中的所有類。
(相互之間沒有緊密聯系的類不應該在同一個包中。)
----包耦合原則
9.無環依賴原則(ADP)
在包的依賴關系圖中不允許存在環。
10.穩定依賴原則(SDP)
朝著穩定的方向進行依賴。
應該把封裝系統高層設計的軟體（比如抽象類）放進穩定的包中，
不穩定的包中應該只包含那些很可能會改變的軟體（比如具體類）。
11.穩定抽象原則(SAP)
包的抽象程度應該和其穩定程度一致。
(一個穩定的包應該也是抽象的，一個不穩定的包應該是抽象的. )
㈢ java處理業務邏輯還是sql處理業務邏輯，希望高手解答
對，這樣無疑對資料庫造成很大壓力。
因為一般公司做的系統都是高並發系統，而服務可以好多個，資料庫只有一個。。
首先長SQL比短SQL佔用的資源多好幾倍，如果很多個請求同時發起，然後數據只能一條一條的處理，導致反應速度慢，如果再狠點，那就資料庫崩掉了。
回過頭來說用代碼處理業務的好處，服務可以有好多個，也就是說可以在好幾個同樣的請求同時發起，短SQL佔用資源少，反應快，瞬間處理結束進行下一個處理，不會佔用資源，導致後續請求響應慢，或者沒有響應。
㈣ 如何寫出復雜業務查詢的sql語句
如何寫出復雜業務查詢的sql語句
如何寫出復雜的sql語句：
首先要建立一個概念，復雜的sql語句也是最基本的sql語句連接而成，所以最重要的是先要理清思路和邏輯，弄清自己要查哪幾張表，要用哪幾個欄位，表之間如何關聯，將這些弄清，然後由簡單到復雜，從最基本的sql寫起，通過找共同點，實現表關聯等。
select後是自己需要的欄位
from後是自己需要查詢的多張表或者自己子查詢得出的結果集
where後是條件 是對from後的結果集進行篩選
多張表關聯 最重要的是找共同點 比如通過userid 第一種方式就是通過join管理 第二種方式就是通過where條件子句 比如幾個表的userid相等來篩
選結果集
在處理復雜的業務查詢時，先從邏輯層面理清幾張表之間的關系以及自己需要的欄位和數據 然後逐步拆分 從最簡單的局部sql出發 一步步迭代出復
雜的sql語句 這可以看做是寫復雜腳本的原則：
由簡單到復雜 逐步迭代 得出結果
最重要的還是在工作實踐中多加總結 主動接觸
㈤ 如果在業務層去拼接sql使用string類型去接收嗎
參考以下：
第一：業務邏輯只涉及到邏輯，不該出現SQL語句拼接，SQL語句拼接應在數據訪問層
第二：調用數據訪問層方法，可以根據返回值來做一個string的返回到用戶界面層
㈥ 開多個線程進行sql查詢,怎麼所有的線程都查詢完成
對於復雜的業務sql查詢，可以考慮如下建議。
1.先通過sql查詢出主表信息列表list.
2.for循環list，補充查詢主表對應的子表信息。
3.在2的步驟中，可以使用多線程處理for查詢。
SQL指結構化查詢語言，SQL使我們有能力訪問資料庫，SQL是一種 ANSI 的標准計算機語言
㈦ 會SQL語句,可以做什麼工作
會SQL 可以做很多工作，下面列舉幾個必須會SQL 的職業：資料庫開發工程師：主要負責寫SQL 代碼，完成一些邏輯功能，常見的報表開發就是這類人做的。DBA ：就是資料庫管理員，負責資料庫的安全與穩定以及性能優化等工作。幾乎所有的工作都需要和SQL 打交道。
SQL
1、以文件形式存儲例如：excel、txt、csv格式。如果數據量很大，超過10萬以上，在excel會發現打開都很困難，運行一個函數或者透視表要等半天。但往往日常要分析的數據量可能遠遠大於這個量級。
隨時目前的大數據時代，對過去一年，二年歷史數據進行分析很正常。另一個在excel要計算相關的數據指標，會發現有時候非常麻煩。例如：計算某個商品連續多少天無銷售；分組統計；計算用戶復購買時間分布。
同時在計算某個指標時候要進行各種條件過濾等在excel基本是無法完成。
2、以資料庫的形式存在於資料庫中。這邊特別說明，我們可以把存儲於大數據平台(hadoop平台或其它技術平台）也可以認為數據是存儲在資料庫中。我們在工作中在後台，或者數據門戶看到的各個數據報表。
數據可視化圖表，各種查詢，後續連接都是資料庫。如果在工作中需要做相關的深入的專題分析，會發現報表中提供的數據往往無法滿足數據分析需要或者相關要分析的數據沒有做成數據可視化或者BI報表。特別是一些新業務。
㈧ SQL如果能表達出復雜的業務邏輯，該怎麼處理
sql如果能表達出復雜的業務邏輯
一個存儲過程的結果集的欄位a 需要從table1裡面取欄位b，通過判斷b欄位 = 1 去取表2數據c
b欄位 = 2 去取表3 sum(欄位c)
b欄位 = 3 去取表4 sum(欄位c)
b欄位 = 4 去取表5 sum(欄位c)
㈨ 如何用SQL語句查詢出業務員每個月的業績和總計
IFOBJECT_ID('saleinfo')ISNOTNULLDROPTABLEsaleinfo
--創建模擬表
createtablesaleinfo(
idintidentity(1,1)primarykey,
salesmannvarchar(50)null,
salemonthnvarchar(50)null,
achievementint
)
--載入模擬數據
insertintosaleinfo(salesman,salemonth,achievement)values('A','1月5日',10)
insertintosaleinfo(salesman,salemonth,achievement)values('A','1月7日',20)
insertintosaleinfo(salesman,salemonth,achievement)values('A','2月4日',30)
insertintosaleinfo(salesman,salemonth,achievement)values('A','2月7日',40)
insertintosaleinfo(salesman,salemonth,achievement)values('A','3月2日',50)
insertintosaleinfo(salesman,salemonth,achievement)values('A','3月9日',60)
insertintosaleinfo(salesman,salemonth,achievement)values('B','1月5日',70)
insertintosaleinfo(salesman,salemonth,achievement)values('B','1月7日',80)
insertintosaleinfo(salesman,salemonth,achievement)values('B','2月4日',90)
insertintosaleinfo(salesman,salemonth,achievement)values('B','2月7日',10)
insertintosaleinfo(salesman,salemonth,achievement)values('B','3月2日',20)
insertintosaleinfo(salesman,salemonth,achievement)values('B','3月9日',30)
insertintosaleinfo(salesman,salemonth,achievement)values('C','1月5日',40)
insertintosaleinfo(salesman,salemonth,achievement)values('C','1月7日',50)
insertintosaleinfo(salesman,salemonth,achievement)values('C','2月4日',60)
insertintosaleinfo(salesman,salemonth,achievement)values('C','2月7日',70)
insertintosaleinfo(salesman,salemonth,achievement)values('C','3月2日',80)
insertintosaleinfo(salesman,salemonth,achievement)values('C','3月9日',90)
--顯示數據
selectsalesmanas業務員,salemonthas月份,achievementas業績fromsaleinfo
declare@sqlvarchar(8000)
set@sql='selectsalesmanas業務員'
select@sql=@sql+',sum(caseleft(salemonth,2)when'''+left(salemonth,2)+'''thenachievementelse0end)['+left(salemonth,2)+']'
from(selectdistinctleft(salemonth,2)assalemonthfromsaleinfo)asa
set@sql=@sql+',sum(achievement)as業績fromsaleinfogroupbysalesman'
exec(@sql)