Question

好的，我明白了。 PostgreSQL中的数据区分大小写。我知道我可以使用LOWER（）来使我的查询不区分大小写。我知道在PostgreSQL的未来版本中甚至可能存在“citext”类型。我的问题是，今天，在设计用户界面时如何处理这个问题？我正在考虑唯一性约束。

假设我的应用程序数据看起来或多或少像文件系统（想想Google Docs，除了Google Docs实际上允许重复名称:-P）。如果案例不同，我怎样才能让我们的用户轻松理解他们可以有重复名称的事实？我想对大多数人来说，它似乎只是怪异。

让我们先发制人地解决一些问题：

我来自Windows背景，因此不区分大小写是我“思考”的方式。我现在主要使用Mac OS X，（你知道吗？）是also case-insensitive。我们的大多数用户都适合这两个桶。
我是PostgreSQL的新手。我的大部分经验都是使用MySQL，但我也使用了Oracle，它像PostgreSQL一样区分大小写。我当时也考虑了很多关于这个问题的内容，但最终将所有内容都保留了原样，让我们的用户只是想出来。
我对两种技术解决方案感兴趣（即解决这个问题）和UI设计解决方案（即帮助用户对系统感到满意）。

要点：

编辑：我感谢目前为止的所有反馈。但是，如果答案是“如果它们因情况不同而不允许重复名称”，那么如何在PostgreSQL中实现？我考虑过的一个解决方案是静默维护一个单独的列，该列始终是数据的LOWER（）版本，并在此列上放置唯一约束。

Answer 1

您现在可以使用citext数据类型。虽然它可能比未来的内置版本有更多限制。

CREATE UNIQUE INDEX
    example_unique_idx
ON
    example_table ((LOWER(case_insensitive_field)));

Answer 2

也许您不了解这一事实，但您可以在功能上创建唯一索引。甚至使它们成为部分索引。

例如：

create unique index some_name on users (lower(username));

无论如何都会使用户名独一无二。

您还可以进一步前进（例如，在您的环境中这可能不是一个好主意），以便仅对活跃用户强制执行唯一性：

create unique index some_name on users (lower(username)) where is_active = true;

另请注意，对于不区分大小写的搜索，不应使用ILIKE。问题是ILIKE不能（出于某些原因我不太懂）使用索引。

因此，虽然可以使用功能索引来加快查询速度：

select * from users where lower(username) = '...'

或

select * from users where lower(username) like '...'

（至少对于“......”的某些值）

在<：p>中不会使用

索引（据我所知）

select * from users where username ilike '...'

Answer 3

区分大小写会迫使您的用户处理计算机世界中的问题。

不要暴露区分大小写！

您刚刚告诉我Windows和Mac都不区分大小写，它们可以减少用户的混淆。

你想要处理的方法是，保留用户选择的情况（用户输入是神圣的），但是当你进行搜索或比较时，它总是没有区分大小写。

Answer 4

在不区分大小写的情况下，您不允许用户创建具有相同名称的对象，除非您有一个非常具体的目标受众已经“获得它”。普通计算机用户Emily Executive不会理解为什么她有两个“季度报告”和“季度报告”文件 - 除非应用程序或使用场景要求区分大小写，否则只会损害产品的可用性。< / p>

换句话说，除非是必需的，否则假设不区分大小写。

如果必须这样做，请强制显示名称不同的字体。提供一个打开和关闭警告的用户选项框，“此文件的名称与此其他文件类似，您确定要将其另存为此名称吗？”随着它在开始时自动打开（退出，不选择通用警告）

- 亚当

Answer 5

实现不区分大小写的另一个技术解决方案是create your own type内置折叠到小写。这样，用户（和应用程序）就不会出错。