数据库语言的目标
要说清这个目标,先要理解数据库是做什么的。
数据库这个软件,名字中有个“库”字,会让人觉得它主要是为了存储的。其实不然,数据库实现的重要功能有两条:计算、事务!也就是我们常说的 OLAP 和 OLTP,数据库的存储都是为这两件事服务的,单纯的存储并不是数据库的目标。
我们知道,SQL 是目前数据库的主流语言。那么,用 SQL 做这两件事是不是很方便呢?
事务类功能主要解决数据在写入和读出时要保持的一致性,实现这件事的难度并不小,但对于应用程序的接口却非常简单,用于操纵数据库读写的代码也很简单。如果假定目前关系数据库的逻辑存储模式是合理的(也就是用数据表和记录来存储数据,其合理性与否是另一个复杂问题,不在这里展开了),那么 SQL 在描述事务类功能时没什么大问题,因为并不需要描述多复杂的动作,复杂性都在数据库内部解决了。
但计算类功能却不一样了。
这里说的计算是个更广泛的概念,并不只是简单的加加减减,查找、关联都可以看成是某种计算。
什么样的计算体系才算好呢?
还是两条:写着简单、跑得快。
写着简单,很好理解,就是让程序员很快能写出来代码来,这样单位时间内可以完成更多的工作;跑得快就更容易理解,我们当然希望更短时间内获得计算结果。
其实 SQL 中的 Q 就是查询的意思,发明它的初衷主要是为了做查询(也就是计算),这才是 SQL 的主要目标。然而,SQL 在描述计算任务时,却很难说是很胜任的。
SQL为什么不行
先看写着简单的问题。
SQL 写出来很象英语,有些查询可以当英语来读和写(网上多得很,就不举例了),这应当算是满足写着简单这一条了吧。
且慢!我们在教科书上看到的 SQL 经常只有两三行,这些 SQL 确实算是写着简单的,但如果我们尝试一些稍复杂化的问题呢?
这是一个其实还不算很复杂的例子:计算一支股票最长连续上涨了多少天?用 SQL 写出来是这样的:
select max (consecutive_day)
from (select count(*) (consecutive_day
from (select sum(rise_mark) over(order by trade_date) days_no_gain
from (select trade_date,
case when closing_price>lag(closing_price) over(order by trade_date)
then 0 else 1 END rise_mark
from stock_price ) )
group by days\_no\_gain)<