150

默认值似乎是大写的，但真的有任何理由为关键字使用大写吗？我开始使用大写字母，因为我只是想匹配 SQL Server 在我尝试创建某些东西时给我的内容，比如一个新的存储过程。但是后来，我的宝宝（第 5 根）手指感觉很糟糕，因为它总是需要按住Shift按钮，所以我停止使用大写字母。为什么我应该回到大写字母？

编辑：谢谢你们的回答。在COBOL为王的时候，我还没有编程，所以我没有意识到这一点。从现在开始，我将坚持使用小写字母。

4

17 回答 17

173

就个人而言，我不喜欢我的 SQL 对我大喊大叫。它让我想起了 BASIC 或 COBOL。

所以我更喜欢带有数据库对象名称 MixedCase 的 T-SQL 小写字母。

它更容易阅读，文字和注释也很突出。

于 2008-11-15T05:13:42.343 回答
124

这只是风格问题，可能起源于编辑不进行代码着色的时代。

我以前更喜欢全部大写，但我现在倾向于全部小写。

于 2008-11-15T02:25:24.927 回答
106

SQL 已过时。大写在喊。它看起来很奇怪，也许很丑。

虽然可以说是正确的，但这些都没有解决SQL 语言的特殊原因，即为什么大写关键字是一个好的约定。

与许多较新的语言不同，SQL 具有大量关键字，并且依赖于读者区分关键字和标识符的能力，以便在心理上解析语法。

那么，对您的问题的直接回答更多的是对“为什么SQL 代码的读者可以从大写关键字中受益如此多，而对于大多数现代语言来说却不是这样？”：

  • 依赖于记住关键字对于许多现代语言来说是合理的，但对于 SQL 来说是不合理的；它有太多的关键字和太多的变体。

  • 依赖标点提示对于大多数现代语言来说是合理的，但对于 SQL 来说是不合理的；它太少了，而是根据关键字的精确顺序来指示语法。

  • 在通常情况下，依靠自动荧光笔来区分关键字对于现代语言来说是合理的，但忽略了荧光笔可以为 SQL 实现的现实。大多数都没有涵盖 SQL 的所有变体的所有关键字，无论如何，在荧光笔无济于事的情况下，经常会经常阅读 SQL。

这些是特定于 SQL 的一些原因，SQL 代码的读者最好通过标准化关键字的大写以及仅使用非大写（即小写或混合）标识符来服务。

突出显示有时会有所帮助。但前提是荧光笔知道你有 SQL；我们经常在编辑器/格式化程序无法合理地知道它正在处理 SQL 的上下文中使用 SQL。示例包括内联查询、程序员文档和另一种语言代码中的文本字符串。对于 Python 或 C++ 等语言，情况并非如此。是的，他们的代码有时确实会出现在这些地方，但通常不会像 SQL 代码那样执行。

此外，读者通常会使用只知道特定 SQL 实现使用的关键字的子集的荧光笔。许多不太常见的关键字不会被突出显示，除非一个非常了解您的 SQL 变体的关键字。所以读者，即使他们使用荧光笔，仍然需要一些更直接的方法来区分任何中等复杂的 SQL 语句中的关键字。

因此，读者将经常——而作者无法提前知道何时会——需要 SQL 语句本身内容的帮助，以了解作者想要作为关键字的内容以及作为标识符的内容。所以SQL 内容本身需要为读者区分关键字，使用大写关键字是常规且有用的方法。

于 2012-08-14T01:53:59.067 回答
39

曾经有一段时间，大多数人无法编码大写字母以外的任何内容，因为相关编码 (ASCII) 尚未发明。只有六个位可用。虽然 SQL 是较新的，但小写字母在编程中还不常见。

请注意，有些人声称数据库将获得紧迫感并更快地运行您的查询。

于 2016-02-28T15:55:51.157 回答
36

Gordon Bell 的例子并不完全正确。通常，仅突出显示关键字，而不是整个查询。他的第二个例子看起来像：

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
于 2008-11-16T08:22:11.103 回答
25

我们阅读的文本中只有不到 10% 的字母是大写的。因此，我们的大脑更热衷于识别小写字母而不是大写字母。研究表明阅读大写文本需要更长的时间。这里只是一个例子：

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

我认为上面的例子强调了即使你只谈论一两个词，它也会产生影响。

于 2011-01-21T19:52:01.413 回答
24

这是因为 SQL 是一门古老的语言（1974 年），以至于当它被构思出来时，大多数键盘都没有小写字母！语言文档只是反映了当时的技术。

研究证明，ALL CAPS 更难阅读，以至于美国联邦公路管理局在其《统一交通控制设备手册》中强制使用混合大小写标志，其中指出：

常规道路引导标志上的地名、街道名、公路名的字体应为小写字母与首字母大写的组合。

《纽约邮报》还发表了：

研究表明，阅读全大写标志更难，而且那些花在远离道路上的额外毫秒已被证明会增加发生事故的可能性，尤其是在老年司机中。

没有充分的理由使用大写字母，也没有充分的理由不使用。

我个人讨厌使用大写的 SQL 关键字。在这个时代，我发现阅读和荒谬变得更加困难。

SQL 语言被定义为不区分大小写。把你的手指从那个shift键上拿开！

于 2012-08-14T03:02:31.723 回答
9

大写可以提高关键字的可见性，但您可以通过代码突出显示和缩进来弥补。
我们使用小写字母是因为查询编辑器和其他工具在编辑 t-sql 代码方面做得很好，我们认为没有必要折磨小指。

于 2008-11-15T02:29:30.693 回答
9

猴看，猴为我做。模式匹配——如果我按照我看到的那样做，从句的结构在心理上更容易排列。

于 2008-11-15T02:45:44.373 回答
7

大写的可读性较差。所有单词的轮廓都像盒子一样；没有下降器或上升器。小写FTW！

于 2008-12-09T07:11:15.560 回答
5

我觉得它更具可读性。每个子句的开头换行和子句之间的缩进也是如此。

于 2008-11-15T02:52:15.187 回答
2

尝试格式化产品（我使用 Red Gate 的 SQL Prompt/SQL Refactor）。您可以设置大小写的工作方式，并且您的代码将始终保持一致的格式。让你的小指休息，让计算机为你完成工作。

于 2008-11-15T03:21:45.017 回答
2

继续使用大写的原因之一是当您（或其他人）在记事本之类的东西中查看代码时，它更容易阅读。即您可以轻松区分“关键字”和表名、SP、udf 等

于 2008-11-15T04:14:12.243 回答
1

除了为了一致性而一致性之外，没有。虽然这是一个非常主观的话题，但我更喜欢对所有 SQL 使用大小写混合。SQL 更容易阅读，并且在现代 IDE 中什么都不会丢失，因为关键字都是用颜色编码的。

于 2008-11-15T04:04:23.170 回答
1

Microsoft SQL Server Management Studio 中的智能感知/自动完成功能允许保留字大写或小写，但大写函数调用如 MAX()、SUM()。

即便如此，解析器仍然允许处理 max() 和 sum() 的小写版本。

这意味着对执行性质的矛盾心理，因此只是个人喜好问题。

于 2011-11-22T21:58:52.703 回答
0

我不喜欢全部大写的任何东西（并且更讨厌全部大写），但无法说服自己反对社区。像往常一样，Vim 及其相关软件包是解决许多问题的方法：

http://www.vim.org/scripts/script.php?script_id=305

只需正常输入，它会在您输入时自动大写关键字。我还没有使用所有晦涩的 SQL 咒语，但它还没有让我失望。

于 2015-08-30T23:30:55.243 回答
-2

我从 PHP 中调用我的大部分 mySQL 代码，并在 vim 中进行所有 PHP 编辑（或者我想在这种情况下是 VIM ;-)。现在我确信有插件可以突出 PHP 中的 mySQL 代码，但我还没有找到它，我也没有时间去寻找它。因此，我更喜欢全部大写。我发现这个：

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？

于 2012-04-23T11:08:55.717 回答