检查文本字段中的长度限制-n约束,而不是使用

时间:2016-04-21 15:36:54

标签: postgresql conventions

SQL语言,特别是PostgreSQL 9+,有很多方法可以做同样的事情......但是在很多情况下(参见Notes sec。的理由)我们需要"削减多样性"并选择标准方式。

有一个tendency to adopt text data type instead varchar。将是"表达字符串的标准方式"在PostgreSQL(!)中,避免在项目讨论中浪费时间并投射相似的格式...... 但是,如何使用text保留大小限制约束

我使用CHECK(char_length(field)<N)并且在实时环境中更改限制没有问题,所以这可能是最好的方式...... 是吗?

一些变化:一般来说什么是最佳选择?

    <{1}}中的
  1. 1.1。数据类型之后的CREATE TABLE,就像默认值定义一样。这是最好的做法吗?

    1.2。所有列定义后CHECK。通常用于CHECK之类的多列声明。

    1.2.1。有些人也喜欢在之后表达所有单独的CHECK,而不是“污染”#34;列声明。

  2. 触发器中使用:有一些优势吗?

  3. 其他方式......其他相关方式?

  4. 1.1,1.2,2或3,最佳做法是什么?

    背景说明

    在有KISSConvention over configuration要求的项目和团队中,我们需要&#34;良好做法&#34;建议......我在CHECK(char_length(col1)<N1 AND char_length(col2)<N2)和项目维护的背景下寻找它。没有无偏见&#34;良好做法&#34; 推荐:Stackoverflow投票是此类推荐的唯一合理记录。

    会议范围

    (编辑)对于个人使用,当然,正如@ConsiderMe所评论的,&#34;无论你选择什么,只要你在整个时间都坚持使用它就会没有问题&#34;。

    另一方面,这个问题是关于&#34; SQL社区&#34; 或&#34; PostgreSQL社区&#34;最佳实践惯例。

2 个答案:

答案 0 :(得分:2)

我喜欢尽可能缩短代码,以便在CHECK约束中使用length(string)。在这种情况下,我没有看到char_length的特定用途 - 它占用了更多的“代码空间”。

在内部,无论如何都是textlen

您应该注意超过1个字节的符号。在这种情况下,我会使用octet_length。例如,考虑字符ą,当要求长度时返回1,当要求octet_length时返回2。在执行不同长度的数据库系统之间进行迁移是一件痛苦的事。

我认为“最佳做法”的良好来源是遵循documentation

它表示使用与列内联的CHECK约束意味着绑定到特定列的列约束。

它提到了表约束,它与任何列定义分开编写,并在多个列之间强制执行数据核心。

基本上在我参与的项目中,我遵循此规则以实现可读性和维护目的。

我甚至不会考虑为这些事情创建触发器。对我来说,它们是为更复杂的任务而设计的。我没有理由在触发器中强制执行简单的数据正确性规则。

我想不出任何其他与标准解决方案一样基本的解决方案,并且仍然像上面提到的那样做得很简单。

答案 1 :(得分:0)

The Depesz article on which this reasoning was based is outdated. The only argument against varchar(N) was that changing N required a table rewrite, and as of Postgres 9.2, this is no longer the case.

This gives varchar(N) a clear advantage, as increasing N is basically instantaneous, while changing the CHECK constraint on a text field will involve re-checking the entire table.