是否有一个很好的理由使用大写的SQL关键字？
默认情况下似乎是大写，但真的有任何理由使用大写的关键字？ 我开始使用大写，因为我只是试图匹配什么SQL Server给我什么时候我试图创build一些东西，如新的存储过程。 但是，我觉得我的宝宝（第五）手指总是需要按住Shift键，所以我停止使用大写字母。 任何我应该回到大写的原因？
编辑：谢谢你的答案。 在COBOL国王的时代，我还没有编程，所以我不知道这一点。 从现在开始，我会坚持小写。
这只是一个风格问题，可能起源于编辑没有做代码着色的时代。
我曾经喜欢所有的大写，但我现在倾向于所有较低的。
个人而言，我不喜欢我喜欢的SQL。 它提醒我的基本或COBOL。
所以我更喜欢我的T-SQL与数据库对象名称混合使用小写。
阅读起来要容易得多，文字和评论也很突出。
SQL是老的。 大写的是SHOUTING。 它看起来很奇怪，很丑。
虽然可以说是正确的，但是没有一个解决SQL语言特殊的原因，为什么大写关键字是一个很好的约定。
与许多较新的语言不同，SQL具有大量的关键字，并依靠读者区分关键字和标识符的能力，从而精神分析语法。
那么，对于你的问题的直接回答就更多的是“为什么SQL代码的读者从大写关键字中受益匪浅 ，而这对于大多数现代语言来说却不是这样”：
-
对于许多现代语言来说，依靠保持关键词是合理的，但对于SQL来说是不合理的 ; 它有太多的关键字，和太多的变种。
-
依靠标点符号对于大多数现代语言来说是合理的，但对于SQL来说是不合理的 ; 它有太less，取决于关键字的确切顺序来表示语法。
-
在通常情况下依靠自动荧光笔来区分关键字对于现代语言来说是合理的，但忽略了荧光笔能够达到的SQL的实际情况 。 大多数不包括所有SQL变体的所有关键字，不pipe怎样，SQL都是在荧光笔无法帮助的上下文中经常和常规读取的。
这些是SQL特有的一些原因，SQL代码的读者最好通过标准化关键字的大写字母来实现 ，而只使用非上层（即较低或混合）的标识符的情况。
突出显示有时可以帮助。 但是，只有当荧光笔知道你有SQL; 而且我们经常在编辑器/格式化程序不能合理地知道它正在处理SQL的上下文中使用SQL。 示例包括在线查询，程序员文档和另一种语言的代码中的文本string。 对于像Python或C ++这样的语言来说，这种情况也是如此; 是的，他们的代码有时会出现在这些地方，但是它并不是像SQL代码那样常规地完成的。
另外，读者通常会使用一个只知道特定SQL实现使用的关键字子集的荧光笔。 许多不太常见的关键字除了知道您的SQL变体的关键字外，不会突出显示。 因此，即使读者使用荧光笔，读者仍然需要一些更直接的方式来区分任何中等复杂的SQL语句中的关键字。
因此，读者经常会 – 而且作者无法提前知道什么时候会 – 需要SQL语句本身内容的帮助，了解作者的意图作为关键字以及意图作为标识符的意图。 因此， SQL内容本身需要区分读者的关键字 ，而使用大写关键字是传统和有用的方法。
戈登·贝尔的例子并不完全正确; 通常，只有关键字被突出显示，而不是整个查询。 他的第二个例子看起来像：
SELECT name, id, xtype, uid, info, status, base_schema_ver, replinfo, parent_obj, crdate, ftcatid, schema_ver, stats_schema_ver, type, userstat, sysstat, indexdel, refdate, version, deltrig, instrig, updtrig, seltrig, category, cache FROM sysobjects WHERE category = 0 AND xtype IN ('U', 'P', 'FN', 'IF', 'TF') ORDER BY 1
我觉得这更容易阅读，因为关键字更突出。 即使使用语法突出显示，我发现这个非资本化的例子也难以阅读。
在我的公司，我们走的更远一点，我们的SQL格式。
SELECT name, id, xtype, uid, info, status, base_schema_ver, replinfo, parent_obj, crdate, ftcatid, schema_ver, stats_schema_ver, type, userstat, sysstat, indexdel, refdate, version, deltrig, instrig, updtrig, seltrig, category, cache FROM sysobjects LEFT JOIN systhingies ON sysobjects.col1=systhingies.col2 WHERE category = 0 AND xtype IN ('U', 'P', 'FN', 'IF', 'TF') ORDER BY 1
我们读的文本中不到10％的字母是大写字母。 因此，我们的大脑比大写字母更容易识别小写字母。 研究表明，阅读大写文本需要更长的时间。 这只是一个例子：
http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals
这是因为SQL是一种古老的语言（ 1974 ），所以当它构思出来时，大多数键盘都没有小写字母！ 语言文档只是反映了当时的技术。
没有很好的理由使用大写字母。 我个人不喜欢使用大写的SQL关键字。 在这个时代阅读起来很难，而且是荒谬的，是不必要的。 SQL语言被定义为不区分大小写。
猴子看，猴子为我做。 模式匹配 – 如果按照我所看到的方式进行，则条款的结构更容易在心理上排列。
大写字母可以提供关键字可见性的增益，但是您可以用代码高亮和缩进进行补偿。
我们使用小写字母，因为查询编辑器和其他工具在编辑t-sql代码方面有奇效，我们看不到折磨小指。
大写字母的可读性较差。 所有单词的轮廓都像盒子一样。 没有下行者或上升者。 小写FTW！
我觉得它更可读。 每个子句的开头都有一个换行符，并在子句之间进行缩进也是一样。
有一段时间，大多数人没有编码任何超过上面的字母的可能性，因为相关的编码（ASCII）还没有被发现。 只有六位可用 。 尽pipeSQL更接近现实，但是在编程时还是不能使用通用的实例。
尝试使用格式化产品（我使用Red Gate的SQL Prompt / SQL Refactor）。 您可以设置如何使大小写工作，并且您的代码将始终格式一致。 rest你的小指，让电脑为你做的工作。
除了整合的缘故，没有。 虽然这是一个非常主观的话题，但我更喜欢对所有SQL使用混合大小写。 SQL更容易阅读，现代IDE中的关键字都是用颜色编码的。
继续使用大写字母的原因之一是当你（或其他人）正在用类似于记事本的方式查看代码时，它使得阅读更容易。 即你可以很容易区分“关键字”和表名，SP的，udf的等
Microsoft SQL Server Management Studio中的智能感知/自动完成允许大写或小写保留字，但大写函数调用如MAX（），SUM（）。
即便如此，parsing器仍然允许处理max（）和sum（）的小写版本。
这意味着对执行的性质有矛盾心理，因此只是个人偏好的问题。
我不喜欢写在所有大写字母上的东西（而且还讨厌input所有的大写字母），但却无法说服自己反对社区。 像往常一样，Vim及其相关软件包可解决如此多的问题：
http://www.vim.org/scripts/script.php?script_id=305
只需键入正常，它会自动大写input关键字。 我没有使用所有晦涩的SQL咒语，但它还没有让我失望。
我从PHP内部调用了大部分mySQL代码，并且在vim中完成了所有的PHP编辑（或者我认为在这种情况下，VIM ;-)。 现在我确信有插件可以突出显示PHP中的mySQL代码，但是我还没有find它，所以我没有时间去查找。 所以，我宁愿拥有一切 。 我觉得这个：
if ( !$bla ) { echo "select something from something where something"; } if ( !$beepboop ) { echo "create table if not exists loremIpsum; } $query = " CREATE TABLE IF NOT EXISTS HISTORY ( ID INT NOT NULL AUTO_INCREMENT, INSERTDATE TIMESTAMP DEFAULT NOW(), ALTERDATE TIMESTAMP(8) DEFAULT NOW(), DELETEDATE TIMESTAMP(8), ALTERCOUNT INT DEFAULT 0, SELECTCOUNT INT DEFAULT 0, PRIMARY KEY(ID), )ENGINE=InnoDB "; mysqlQuery( $query, $con );
帮助我区分PHP和SQL比这更好：
if ( !$bla ) { echo "select something from something where something"; } if ( !$beepboop ) { echo "create table if not exists loremIpsum; } $query = " create table if not exists history ( id int not null auto_increment, insertdate timestamp default now(), alterdate timestamp(8) default now(), deletedate timestamp(8), altercount int default 0, selectcount int default 0, primary key(id), )engine=InnoDB "; mysqlQuery( $query, $con );
另外，由于某种原因，我讨厌把所有的头像和骆驼混在一起，就像这样：
CREATE TABLE IF NOT EXISTS history ( ID INT NOT NULL AUTO_INCREMENT, insertDate TIMESTAMP DEFAULT NOW(), alterDate TIMESTAMP(8) DEFAULT NOW(), deleteDate TIMESTAMP(8), alterCount INT DEFAULT 0, selectCount INT DEFAULT 0, PRIMARY KEY(ID), )ENGINE=InnoDB
这个ID我感到厌烦。 应该改为id吗？ 或iD ？
