PostgreSQL 命名约定

发布于 2024-09-02 11:52:19 字数 66 浏览 0 评论 0原文

在哪里可以找到有关 PostgreSQL 命名约定的详细手册? (表名与驼峰式大小写、序列、主键、约束、索引等...)

Where can I find a detailed manual about PostgreSQL naming conventions? (table names vs. camel case, sequences, primary keys, constraints, indexes, etc...)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

无需解释 2024-09-09 11:52:19

关于表名称、大小写等,普遍的约定是:

  • SQL 关键字:大写
  • 标识符(数据库、表、列等的名称):lower_case_with_underscores

例如

UPDATE my_table SET name = 5;

这不是一成不变的,而是关于 < IMO 强烈建议使用小写标识符。 Postgresql 在未引用时不区分大小写(实际上在内部将它们折叠为小写),在引用时区分大小写;许多人并没有意识到这种特质。始终使用小写字母是安全的。无论如何,使用 camelCasePascalCase(或 UPPER_CASE)是可以接受的,只要你保持一致:要么总是引用标识符,要么从不引用标识符(并且这包括模式创建!)。

我不知道还有更多的约定或风格指南。代理键通常由序列组成(通常使用 < code>serial 宏),如果您手动创建这些序列(tablename_colname_seq),那么坚持这些序列的命名会很方便。

另请参阅一些讨论 此处此处 和(对于一般 SQL)

注意:Postgresql 10 引入了 identity 列: serial 的 SQL 兼容替代品。

Regarding tables names, case, etc, the prevalent convention is:

  • SQL keywords: UPPER CASE
  • identifiers (names of databases, tables, columns, etc): lower_case_with_underscores

For example:

UPDATE my_table SET name = 5;

This is not written in stone, but the bit about identifiers in lower case is highly recommended, IMO. Postgresql treats identifiers case insensitively when not quoted (it actually folds them to lowercase internally), and case sensitively when quoted; many people are not aware of this idiosyncrasy. Using always lowercase you are safe. Anyway, it's acceptable to use camelCase or PascalCase (or UPPER_CASE), as long as you are consistent: either quote identifiers always or never (and this includes the schema creation!).

I am not aware of many more conventions or style guides. Surrogate keys are normally made from a sequence (usually with the serial macro), it would be convenient to stick to that naming for those sequences if you create them by hand (tablename_colname_seq).

See also some discussion here, here and (for general SQL) here, all with several related links.

Note: Postgresql 10 introduced identity columns as an SQL-compliant replacement for serial.

淡淡绿茶香 2024-09-09 11:52:19

并没有真正的正式手册,因为没有单一的样式或标准。

只要你了解标识符命名规则你可以使用任何你喜欢的东西。

在实践中,我发现使用 lower_case_underscore_separated_identifiers 更容易,因为没有必要在任何地方都使用 “双引号” 它们来保留大小写、空格等。

如果您想命名你的表和函数 "@MyAṕṕ! ""betty"" Shard$42" 你可以自由地这样做,尽管到处打字会很痛苦。

需要理解的主要内容是:

  • 除非用双引号括起来,否则标识符将大小写折叠为小写,因此 MyTableMYTABLEmytable 都是同一件事,但 "MYTABLE""MyTable" 是不同的;

  • 除非双引号:

    <块引用>

    SQL 标识符和关键字必须以字母(az,也可以是带变音符号的字母和非拉丁字母)或下划线 (_) 开头。标识符或关键字中的后续字符可以是字母、下划线、数字 (0-9) 或美元符号 ($)。

  • 如果您希望将关键字用作标识符,则必须用双引号引起来。

在实践中,我强烈建议您不要使用关键字 作为标识符。至少避免保留字。仅仅因为您可以将表命名为 "with" 并不意味着您应该这样做。

There isn't really a formal manual, because there's no single style or standard.

So long as you understand the rules of identifier naming you can use whatever you like.

In practice, I find it easier to use lower_case_underscore_separated_identifiers because it isn't necessary to "Double Quote" them everywhere to preserve case, spaces, etc.

If you wanted to name your tables and functions "@MyAṕṕ! ""betty"" Shard$42" you'd be free to do that, though it'd be pain to type everywhere.

The main things to understand are:

  • Unless double-quoted, identifiers are case-folded to lower-case, so MyTable, MYTABLE and mytable are all the same thing, but "MYTABLE" and "MyTable" are different;

  • Unless double-quoted:

    SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($).

  • You must double-quote keywords if you wish to use them as identifiers.

In practice I strongly recommend that you do not use keywords as identifiers. At least avoid reserved words. Just because you can name a table "with" doesn't mean you should.

阪姬 2024-09-09 11:52:19

这里唯一的两个答案是 6 岁的我不知道蛇是否是最好的情况是真的。这是我对现代的看法。另外,放弃任何需要双引号的额外复杂性。我认为流畅比试图避免轻微的不便更重要。

由于没有严格的指导方针/风格指南,我认为最好使用与项目代码相同的情况。例如,在 JavaScript 等语言中使用 OOP 方法,表名称将采用 PascalCase,而属性将采用 CamelCase。如果您采用函数式方法,它们都是驼峰命名法。另外,按照惯例,JS 类是 PascalCase,属性是 CamelCase,所以无论如何它都是有意义的。

另一方面,如果您使用 SqlAlchemy 在 Python 中进行编码,那么只有对函数派生模型使用 Snake_case 名称,对类派生模型使用 PascalCase 名称才有意义。在这两种情况下,属性/列都应该是snake_case。

The only two answers here are 6 years old idk if snake_case being the best case is true anymore. Here's my take on modern times. Also, forgoing any extra complication of needing to double-quote. I think flow is more important than trying to avoid a minor inconvenience.

Provided by the fact that there are no strict guidelines/style guides, I'd say it is best to use the same case as project code. So for example, using OOP approach in languages like JavaScript, table names would be in PascalCase where as attributes would be in camelCase. Where as if you're taking the functional approach, they'd both be camelCase. Also, by convention JS classes are PascalCase and attributes are camelCase so it makes sense anyways.

On the other hand, if you are coding in Python using SqlAlchemy then it only makes sense to use snake_case names for function-derived models and PascalCase names for class-derived models. In both cases, attributes/columns should be snake_case.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文