3

我们正在将以前使用 Openbase 7 的应用程序移植到现在使用 MySQL 5.0。

OB 7 在区分大小写方面确实有非常糟糕的定义（即未记录的）行为。我们现在只是在使用 MySQL 尝试相同的查询时才发现这一点。

看起来 OB 7 处理使用“=”的查找与使用“LIKE”的查找不同：如果您有两个值“a”和“A”，并使用 WHERE f="a" 进行查询，那么它只会找到“ a”字段，而不是“A”字段。但是，如果您使用 LIKE 而不是“=”，那么它会同时找到两者。

我们对 MySQL 的测试表明，如果我们使用非二进制排序规则（例如 latin1），那么“=”和“LIKE”都会不区分大小写。然而，为了模拟 OB 的行为，我们只需要让“=”区分大小写。

我们现在正试图弄清楚如何在 MySQL 中处理这个问题，而不必为我们所有的查询添加大量的 LOWER() 函数调用（有很多！）。

我们可以完全控制 MySQL 数据库，这意味着我们可以随意选择它的排序模式（幸运的是，我们的表名和唯一索引不受区分大小写问题的影响）。

任何建议如何以最少的代码更改模拟 MySQL 上的 OpenBase 行为？

（我意识到在我们的源代码中添加 LOWER 调用的一些智能正则表达式替换可能会起到作用，但我们宁愿找到不同的方法）

4

4 回答 4

2

另一个想法.. MySQL 是否提供类似用户定义函数的功能？然后，您可以编写一个不区分大小写的 UDF 版本（ci_like 左右），并将所有 like 更改为 ci_like。可能比正则表达式调用 lower in 更容易做到。

于 2009-01-29T18:50:34.717 回答
0

这两篇文章讨论了mysql中的区分大小写：

两者都是谷歌搜索的早期热门：

于 2008-12-18T15:17:38.977 回答
0

我知道这不是您要寻找的答案..但是鉴于您想保持这种行为，您不应该明确地对其进行编码（而不是在某处更改一些神奇的“配置”）吗？

这可能是一项相当多的工作，但至少您会知道代码的哪些区域受到影响。

于 2009-01-28T07:01:06.243 回答
0

快速浏览一下MySQL 文档似乎表明这正是 MySQL 的做法：

这意味着如果您使用 col_name LIKE 'a%' 进行搜索，您将获得所有以 A 或 a 开头的列值。

于 2009-01-30T08:16:27.553 回答