postgresql 命名

                                    postgresql 命令规范：

 为什么命名如此重要：

  a) : 名字使用时间很长：

        数据结构的使用时间是比应用代码还长的， 从任何人都一直在运行的系统上工作可以看出来。

 b) : 名字具有缔结关系：

        数据库对象都是通过他们的名字来引用的， 因此 对象名就像链接对象的部分那样， 在某个方面来看， 你可以将你的数据库表和列名当做你自己数据库模型里的api 一样。

c) : 开发者上下快速选择：

       在数据库拥有一致的命名规范 意味着 你将花更少的时间去查找表名， 视图， 和列， 这样就更能够专注于写sql和debug sql ， 你也能够快速了解到你所用的的数据是来自那个表的那个列。

- ----------------------------------------------------------------------------------------------------------------------------------------

    命名规范：

a) : 避免双引号：     

      使用双引定义非常痛苦， 通过  " 的标记符写的sql是非常让人沮丧。 

                尽量避免 使用 " FirstName" or "all ements" 之类的名字。

b) : 小写：

        标记符 ：名字应该应该全部写成小写（包括 表名， 视图，列 ...） ,混合大小写的话，可能就需要用双引号 引起， 这在之前就提过是不提倡。

c） 数据类型不能作为名字：

            数据类型名不应该作为名字用在字段和对象中， 尽量避免像 "text" 和"timestamp" 等，特别是前者是对应对象的零值时。

d:) 下划线分离单词：

            我们对象名包含多个单词时，应该通过下划线来分别多个单词，例如通过word_count 代替 wordcount.

E): 全拼， 而不是缩写：

            对象应该全称，而尽量避免缩写， 特别是，当把元音消除后就是类型， 大多数都支持30个 以上的字符 ，postgresql 更是支持63个字符来作为标记。

F): 使用通用好理解的缩写：

        如果是特别长的单词组合， 如果有更好的方式缩写方式比单词本身更通解，例如：

    "Internationalization" and "localization"  更适合写 i18n , 在这些情况下， 使用缩写；

    假如你不肯定好理解的话， 那就使用英文全称， 那样明显是比缩写有理解意义的。

e:) 避免使用保留字：

  尽量避免使用数据库的保留字，由于他们不是太多，也不会太多去考虑到他们，有时也要依上下文看， 有时保留字还需要 “”” ；

    还有就是 在不难只能的编辑器里，语法高亮将不会特别显示错误高亮； 避免使用 user or  table or lock 之类的。

-------------------------------------------------------------------------------------------------------------------------------------------

单数关系：

  我们在为 表， 视图，列，命名时， 更加的是单数名字，而不是复数，eg： named team ， 而不是 teams.

 使用单数， 更好理解， 具有一致性，明确，简单直接。

 

----------------------------------------------------------------------------------------------------------------------------------------------

关键字：

     a): 主键：

        单一列的主键字段应直接命名为  id  ,简单，直接， 明确， 这样就在联合时根本不用记住这个字段， 当有些想在前面加上表名，eg : persion_id vs id  ， 这有点冗余； 所有的字段在不简单的sql  语句中， 使用命名空间那样的命名方式 是一个不好的idea;

    b): 外键：

      外键应该有引用外部表的名字和外部所对应字段的名字，例如 foo_id (refence_table_ refence_fields)

        -------------------------------------------------------------------------------------------------------------------------------

前缀和后缀（are bad）：

 a): 关系类型前缀：

之前有把 表名TB-xx ,view with vw_xx, 这个在不清楚sql具体含义是能够直接通过它，继而能够识别这些名字， 但  这是个bad idea；

  你可以使用视图来建立新表以取代 一些加前缀名的表名，在postgresql 中， 在view中 进行dml 操作 是

一个非常强力的特点；

在为表名命名时， 添加表名类型前缀是会造成更加混乱的。(在sql 中查找）

 b:) 应用名前缀：

   现代数据库支持自己本身的命名空间格式， eg pg 创建 schemas 管理数据库对象， 这样更为简洁和方便，除非是支持一些额外的插件和框架是需要插件或者框架前缀的，所以在一般的数据库中， 没有添加应用名作为前缀的必要。

c): 数据类型前缀：

     另外一种老旧的说法是，添加字段类型作为前缀，同样这是一种不好命名方式，  因为 int_前缀很可能变成bigint or  numeric, 所以这是不能完全定死的。

-----------------------------------------------------------------------------------------------------------------------------------------

精确命名：

   一些数据库命令或者orm 直接会默认生成一些随机的名字， 除非你知道怎么生成，并且乐于接受他， 否者， 你应该自己精确的命名。

indexes:

         索引应该包括表名和列名， 这样的话就更能够理解好sql语句，查找对应的属性。

constraints:

      就像索引， 约束也应该添加描述性的名字，那样在你进行插入等操作时， 会让你更能够诊断出错误在哪。

final thougths:

   the only thing  worse than bad naming conventions is multiple name conventions, if your existing project already has a standard approach to naming its database objects then keep using it.

  参考来自：  https://launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/#target-audience

        

转载于:https://my.oschina.net/longtian/blog/736314