SQL关键词正式定义材料

时间:2012-04-24 23:19:01

标签: sql keyword definition

我在网上寻找一个体面的教程或文章,只是正式定义SQL中的每个关键字(至少对于初学者)意味着什么,以及它如何与其他SQL关键字结合起来。我想知道在什么之前执行什么,它是如何完成的,以及它是如何正式定义的。

我得到的只是大量的例子,我浪费时间而不仅仅知道一个关键字真正做到了什么,关于它如何完成将会很高兴知道。

为什么人们想知道这一点并非微不足道?为什么我打开的关于SQL的每本书和每个网站都是通过示例进行教学而不是正式给出每个关键字的定义,就像在Java的核心类方法实现中一样。

我只是不明白;你能解释一下原因吗?

2 个答案:

答案 0 :(得分:4)

SQL代表着一个古老的笑话"几乎没有资格作为一种语言"。 SQL查询更像是一个规范而不是一个程序:你描述你想要的东西 - 和自然语言一样,不仅仅是一种说同样的方式 - 系统可以自由地以任何方式实现它只要满足要求**它就认为合适。

我完全可以推荐这本书SQL and Relational Theory: How to Write Accurate SQL Code By C. J. Date。虽然它可能并不能完全满足您的要求,但它确实解释了SQL的理论基础及其与它的偏差。

有一点需要注意的是,SQL标准已经发展了多年,没有任何东西被弃用(称为"兼容性的束缚"),导致(IMO)一种不直观,用户不友好的语言。 SQL的严格SELECT..FROM..WHERE,逻辑上执行FROM..WHERE..SELECT,这意味着SQL中的投影冗长而且价格昂贵,只是SQL缺乏的一个例子。灵活性。


  

我真的很难相信到现在还没有人真正理解   足够的SQL完全能够准确地区分每个键   这样做,以及以什么顺序。

Joe Celko写了很多关于这种东西的文章。以下是google的一些确切短语:

"以下是SELECT在SQL中的工作原理......至少在理论上是这样的。"

"以下是OUTER JOIN在SQL-92"

中的工作方式

"搜索到的更新语句的正确语法是"

" CASE不是开关;它是SQL"

中的**表达式**

那就是说我已经看到SQL Server的漏洞被关闭了,因为它没有被修复'因为尽管结果是错误的,但优化仍然存在!

答案 1 :(得分:2)

至少有几个问题:

  1. 该标准有很多版本:1986年,1989年,1992年(大约在1996年左右),1999年,2003年,2008年和2011年版本。
  2. 这些天标准有多个部分。有SQL / Foundation(核心SQL),但也有很多可选扩展。
  3. 每个DBMS都有自己的SQL标准扩展,它们都省略了标准的某些方面。
  4. 您可以找到某些可用标准here的BNF(Backus-Naur格式)语法。这些是重度超链接的HTML。但是,标准不仅仅是SQL语法;关于在标准的其余部分中何时何地(并且通常没有多少解释原因)允许的内容,有很多(以及很多很多)规则。该标准有时几乎是不透明的。

    以下是来自ISO / IEC 9075-2:2003(E)的驯服示例 - 这是SQL-2003的SQL / Foundation:

      

    10.7 <collate clause>

         

    功能

         

    指定默认排序规则。

         

    格式

    <collate clause> ::= COLLATE <collation name>
    
         

    语法规则

         

    1)设C为<collation name>中包含的<collate clause>。由显式或。标识的模式   <collation name>的隐式限定符应包括C的描述符。

         

    访问规则

         

    1)案例:

         

    a)如果<collate clause>中包含<SQL routine spec>,而在<SQL schema statement>中没有指定SQL安全调查员的干预<authorization identifier>,则适用的权限为   拥有包含模式的<privileges>应包括C上的USAGE。

         

    b)否则,当前特权应包括C上的USAGE。

         

    注228 - “适用特权”和“当前特权”在第12.3节“<collate clause>”中定义。

         

    一般规则

         

    无。

         

    一致性规则

         

    1)如果没有Feature F690,“归类支持”,符合SQL的语言不得包含<cast specification>

    一个不太温和的例子是<time precision>有16页的gobbledygook描述它。这是从大约2/3的方式。这是“一般规则”第16号(满分20分):

      

    16)如果TD是日期时间数据类型TIME WITH TIME ZONE,那么让TSP成为TD的TRIM ( BOTH ' ' FROM VE )

         

    案例:

         

    a)如果SD是字符串,则SV替换为:

    <literal>
         

    案例:

         

    i)如果第5.3条“<unquoted time string>”中<literal><literal>的规则可以是   应用于SV以确定数据类型TD的有效值,然后让TV成为该值。

         

    ii)如果第5.3条“<unquoted time string>”中<literal> CAST ( TV1 AS TIME(TSP) WITH TIME ZONE ) 的规则可以是   应用于SV以确定数据类型TIME(TSP)WITHOUT TIME ZONE的有效值,   那么让TV1成为那个价值,让电视成为价值:

    <datetime value>
         

    iii)如果<primary datetime field>不符合日期或时间的自然规则,则根据   格里高利历,然后引发异常条件:数据异常 - 无效的日期时间   格式。

         

    iv)否则,会引发异常情况:数据异常 - 强制转换的字符值。

         

    b)如果SD为TIME WITH TIME ZONE,则TV为SV,具有实现定义的舍入或截断   如果有必要的话。

         

    c)如果SD为TIME WITH TIME ZONE,则TV的UTC分量为SV-STZD,计算出来   模数为24小时,必要时执行定义的舍入或截断,以及时区   电视的组成部分是STZD。

         

    d)如果SD是TIMESTAMP WITH TIME ZONE,那么TV的UTC组件是小时,分钟和   SV的第二个CAST ( CAST ( SV AS TIMESTAMP(TSP) WITH TIME ZONE ) AS TIME(TSP) WITH TIME ZONE ) ,如果需要,可以实现定义的舍入或截断,   电视的时区成分是SV的时区位移。

         

    e)如果SD是没有时区的TIMESTAMP,那么电视是:

    {{1}}

    标准中的缩进稍微好一些,你可以为某些名称(例如电视,SV,SD等)提供更多的上下文,但使用的语言确实非常糟糕。 / p>