官方PostgreSQL大写惯例

Question

是否有关于DB、表和字段名大写化的正式PostreSQL约定？

官方网站上的例子建议用小写和_分隔词，我不知道这一政策是否是正式的。

CREATE TABLE films (
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
    title       varchar(40) NOT NULL,
    did         integer NOT NULL,
    date_prod   date,
    kind        varchar(10),
    len         interval hour to minute
);

Answer 1

我将基本上照搬Verace的评论并声明这一点，使它成为半官方的：

没有一种最佳做法能涵盖每一种情况。下面的内容做出了以下假设(如果您还没有这样做，那么应该做什么)：

• 你已经和你的团队讨论过这件事了(那些独自工作的人常常不得不下定决心)。
• 您的团队中已经没有SQL的正式样式定义(否则您不会问我们)。
• 没有对任何代码进行形式化样式定义(遵循已经为其他语言建立的基本约定，并将样式正式化)

因此，其余的部分都有些固执己见，但基于经验。

1. 当涉及到表名
   1. 您应该选择单一的实体名称(这使文档变得更容易)
   2. 你应该在这里用Pascal的例子

2. 当涉及到字段名时
   1. 在字段名上使用camelCase
   2. 使用短短的单数名称，除非该定义确实具有复数意义(它几乎从不使用)

3. 当涉及到您自己的函数或存储过程名称时，
   1. 使用underscore_separation
   2. 使用字段命名进行参数化

4. 当涉及到内置数据库函数或语言名称(例如选择)时，
   1. 除非需要以某种方式将其资本化，否则请使用所有的上限
   2. 了解您的语言的API以了解什么是合理的或什么是必需的

5. 当涉及到间距时
   1. 许多人使用列对齐作为关键字，而缩进则用于非关键字的内容。
   2. 当每一行的字段被分隔开时，许多人在行的开头使用逗号(这使得将特定字段从选择列表中注释掉更容易)。
   3. 不要将空格作为事物名称的一部分，甚至不用于返回值标头。

6. 当谈到标点符号时，
   1. 括号-使用它们。他们是自由的。我保证。
   2. 分号-用它们。他们不会打垮你的。他们强迫你想出你的代码。而且它们很卫生。
   3. 回车-再一次，它们是免费的;-)，并使您的代码可读性。

您还应该认识到，在我试图帮助您应用通用样式指南时，Postgres社区通常不使用camelCase或PascalCase，而是使用underscore_separation。真正重要的一点是确保您在任何地方都建立和使用特定的样式以保持一致。

Answer 2

一个快速的谷歌将揭示许多网站，表明最佳做法。我只想说两件事--永远不要使用空格“我的表名”(移植由于不同的转义机制而变得不可能；对于任何非字母数字字符也是如此)。有了这种机制，你通常也要尊重案例。英语(或您自己的)语言中有足够多的字母和单词，标识符的长度也足够长(我不知道有哪个系统的identifier_length < 32，PostgreSQL是64)。也不要使用SQL关键字(根据RDBMS的不同)来做同样的事情。

诸如此类

SELECT "Field" FROM "Table";

是有效的！绝对关键的是要有一个清晰和相对简单的惯例，然后坚持下去。人们有不同的意见，因为你会发现-阅读主题，并选择什么“感觉对”你。看看这些网站1，2，3.，4.，5，.(还有更多)。