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)