对于 SQL 关键字使用大写是否有充分的理由？

默认值似乎是大写，但是真的有什么理由对关键字使用大写吗？

我开始使用大写，因为我只是试图匹配什么 SQL Server给我每当我尝试创建一些东西，如一个新的 存储过程。但是，我为我的宝贝(第五)手指感到难过，它总是需要按下 Shift按钮，所以我停止使用大写。有什么理由让我回到大写字母吗？

60864 次浏览
小开
最佳答案

这只是一个风格问题，可能起源于编辑器不使用代码着色的日子。

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

不管怎样，要始终如一。

小开

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

小开

猴子看，猴子为我做。模式匹配-如果我用我见过的方法来做，从句的结构在心理上更容易排列。

小开

我觉得更易读。每个子句的开头都有一个换行符，子句之间也有缩进。

小开

尝试一个格式化产品(我使用来自 Red Gate 的 SQL Prompt/SQL Refactor)。您可以设置大小写的工作方式，并且代码始终保持一致的格式。让你的小指休息，让电脑为你工作。

小开

除了为了一致性而遵从，没有。尽管这是一个非常主观的主题，但我更喜欢对所有 SQL 使用混合大小写。SQL 更容易阅读，而且在现代 IDE 中没有丢失任何东西，因为关键字都是彩色编码的。

小开

继续使用大写的原因之一是当您(或其他人)在类似记事本的东西中查看代码时，它使阅读更加容易。也就是说，你可以很容易地区分“关键字”和表名、 SP、 udf 等

小开

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

所以我更喜欢我的数据库对象名称为 MixedCase 的 T-SQL 小写形式。

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

小开

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
小开

大写字母的可读性较差。所有单词的轮廓都是盒子形状，没有下行和上行。小写 FTW！

小开

我们阅读的课文中只有不到10% 的字母是大写。因此，我们的大脑在识别小写字母时比识别大写字母时更加敏锐。研究表明，阅读大写文本需要更长的时间。这里只有一个例子:

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

我认为上面的例子强调，即使你谈论的只是一个或两个单词，它也会产生差异。

小开

在 Microsoft SQL Server 管理工作室中智能感知/自动完成允许大写或小写的保留字，但大写的函数调用，如 MAX () ，SUM ()。

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

这意味着对处决的性质存在矛盾心理，因此只是个人偏好的问题。

小开

我在 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？

小开

SQL 已经过时了。大写字母是大喊大叫。它看起来很奇怪，也许很丑陋。

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

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

那么，对你的问题的直接回答更多的是“为什么 SQL 代码读者的好处如此多地使用大写关键字，而大多数现代语言却不是这样?”:

  • 对于许多现代语言来说，依赖于保持 头脑中的关键词是合理的，但是对于 对 SQL 来说是不合理的; 它有太多的关键字和太多的变体。

  • 对于大多数现代语言来说，依赖 标点线索是合理的，但是对于 对 SQL 来说是不合理的; 它的数量太少，而是取决于表示语法的关键字的精确顺序。

  • 对于现代语言来说，依靠 自动荧光笔自动荧光笔来区分关键词在一般情况下是合理的，但是 忽略了高亮显示器可以为 SQL 实现的功能。大多数情况下不会涵盖所有 SQL 变体的所有关键字，而且不管怎样，SQL 在高亮显示器不起作用的上下文中经常被定期读取。

这些是特定于 SQL 的一些原因，即 SQL 代码的读者最好使用 关键字大写标准化，并且只使用非上(即低，或混合)大小写作为标识符。

突出显示有时会有帮助。但是，只有在高亮显示器知道您已经使用了 SQL 的情况下，而且我们经常在编辑器/格式化程序无法合理地知道它正在处理 SQL 的上下文中使用 SQL。示例包括内联查询、程序员文档和另一种语言代码中的文本字符串。对于 Python 或 C + + 这样的语言来说，情况并非如此; 是的，它们的代码有时确实会出现在这些地方，但它们并不像 SQL 代码那样经常出现。

此外，读取器通常使用高亮显示器，它只知道特定 SQL 实现使用的关键字的子集。许多不太常见的关键字不会被突出显示，除非有一个非常熟悉 SQL 变体的关键字。因此，即使使用高亮显示器，阅读器仍然需要一些更直接的方法来区分任何中等复杂的 SQL 语句中的关键字。

因此，读者经常需要 SQL 语句本身的内容来帮助他们了解作者想要把什么作为关键字，把什么作为标识符。因此，SQL 内容本身需要 为读者区分关键词，而使用大写关键字是实现这一点的常规和有用的方法。

小开

这是因为 SQL 是一种非常古老的语言(1974年) ，在构思它的时候，大多数键盘都没有小写字母！语言档案编制只是反映了当时的技术。

科学研究已经证明 ALL CAPS 更难读，以至于美国联邦公路管理局在他们的统一交通控制设备手册中强制使用混合案例标志，其中规定:

常规道路标志上的地名、街名、公路名称，应当由小写字母和首字母大写字母组成。

《纽约邮报》还发表了:

研究表明，阅读大写字母的标志更加困难，而且那些花费在盯着远离道路的额外毫秒时间已被证明会增加事故发生的可能性，特别是在老年司机中。

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

我个人不喜欢对 SQL 关键字使用大写。我发现在这个时代很难读懂，也很荒谬。

SQL 语言被定义为不区分大小写！

小开

我不喜欢用大写字母写的东西(更不喜欢用大写字母写的东西) ，但我无法说服自己去反对这个社区。像往常一样，Vim 及其相关的软件包是许多问题的解决方案:

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

简单的键入正常，它会自动大写的关键字，因为你键入。我没有使用所有晦涩的 SQL 咒语，但它还没有让我失望。

小开

曾经有一段时间，大多数人不可能编码超过大写字母的任何东西，因为相关的编码(ASCII)还没有发明出来。只有六个位可用.虽然 SQL 是最近才出现的，但小写字母在编程中并不常见。

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


提交答案