Question

我们刚刚将DEVEL的SQL Server 2005数据库“迁移”到了TEST中。不知何故，在迁移过程中，数据库从不区分大小写变为敏感 - 因此大多数SQL查询都破坏了。

我想知道的是 - 拥有区分大小写的架构有什么明显的好处吗？

注意：我的意思是表名，列名，存储过程名等。我不是指存储在表中的实际数据。

在第一次检查时，我找不到提供优于不区分大小写的好处的正当理由。

Answer 1

我刚刚发现了为什么我们让它区分大小写。这是为了确保当我们在客户端站点上部署它时，无论客户端的SQL Server是否设置为区分大小写，我们的数据库都能正常工作。

这是我没想到的一个答案。

Answer 2

我真的想不出有什么好的理由SQL标识符应区分大小写。我可以想到一个 bad ，一个MySQL给出的为什么他们的表名称区分大小写。每个表都是磁盘上的文件，您的文件系统区分大小写，MySQL开发人员忘记了table_file = lc(table_name)。将MySQL模式移动到不区分大小写的文件系统时，这很有趣。

我能想到他们不应该区分大小写的一个重要原因。

某些架构作者会变得聪明，并认为this_table显然意味着与This_Table不同，并制作这两个表（或列）。您也可以在架构中的那一点写下“在这里插入错误”。

此外，不区分大小写使您在SQL中更具表现力，可以强调表和列与命令，而不必遵循架构作者的决定。

SELECT this, that FROM Table;

Answer 3

并非Unicode的所有部分都有大写和小写字符之间的双射映射 - 甚至是两组案例。

在这些地区，“不区分大小写”有点无意义，可能会产生误导。

这就是我现在能想到的一切;在ASCII集中，除非你想让Foo和foo不同，否则我没有看到这一点。

Answer 4

大多数语言都区分大小写，大多数比较算法，大多数文件系统等都是区分大小写的。对于懒惰用户，不区分大小写。虽然它确实倾向于使事情更容易打字，并且确实导致许多相同名称的变体只有大小写不同。

就个人而言（MyTable，mytable，myTable，MYTABLE，MYTable，myTABLE，MyTaBlE），我希望看到一个通用版本。

Answer 5

如果开发人员在编写SQL时未能遵循任何约定，或者来自开发语言（如不区分大小写，例如VB），则不区分大小写是一种天赐之物。

一般来说，我发现处理数据库更容易，因为ID，ID和Id不可能是不同的字段。

除了个人偏好酷刑之外，我强烈建议你坚持不区分大小写。

我曾经为此设置的唯一一个案例敏感性的数据库是Great Plains。我发现必须记住他们的模式命令的每一个外壳是痛苦的。我没有权利使用更新的版本。

除非它已经改变并且我的记忆服务，否则您所说的区分大小写的性质是在安装时确定的，并且适用于所有数据库。运行Great Plains数据库的SQL Server安装就是这种情况，我提到该安装上的所有数据库都区分大小写。

Answer 6

我喜欢区分大小写，主要是因为这是我习惯使用Perl编程（以及大多数其他语言）。我喜欢将StudlyCaps用于表名，所有小写字母用下划线表示列。

当然，许多数据库允许您引用名称来强制执行大小写，就像Postgres一样。这似乎也是一种合理的方法。

Answer 7

我支持Sybase Advantage数据库服务器，它使用平面文件格式，允许使用DBF以及我们自己专有的ADT格式。我认为区分大小写是一个问题的情况是使用我们的Linux版本的服务器。 Linux是一个区分大小写的操作系统，因此我们在db中有一个选项可以小写所有调用。这要求表文件为小写。

Answer 8

我非常确定SQL Spec需要对标识符进行大小写折叠（实际上与不敏感性相同）。 PostgreSQL折叠降低，ORACLE折叠到更高。

区分大小写的数据库有好处吗？

8 个答案: