使用 UUID 和 Oracle 的 NLS_COMP 和NLS_SORT 设置
我的表使用 UUID 作为主键，并将它们作为 CHAR(36) 存储在 Oracle DB 中。大多数表包含可以采用任何语言的 NVARCHAR 列。我想支持这些列上的自然语言排序，我通过在 oracle 会话上设置 NLS_SORT 和 NLS_COMP （通过 ALTER SESSION）来实现这一点。我遇到的问题是，oracle 不会在 UUID 列上使用二进制索引，并且始终执行全表扫描。
有没有办法在不丢失二进制索引的情况下获得排序效果？我发现的一种解决方案是使用 RAW(16) 来表示 UUID，在这种情况下，Oracle 将使用二进制索引，而不管 NLS 排序/压缩如何。但我希望有更好的选择。
有什么建议吗？
My tables use UUIDs as primary keys and store them in an Oracle DB as CHAR(36). Most of the tables contain NVARCHAR columns that could be in any language. I would like to support the natural language sort on these columns and I do that by setting NLS_SORT and NLS_COMP on the oracle session (via ALTER SESSION). The problem I'm hitting is that oracle will not use the binary indexes on the UUID columns and always do full table scans.
Is there anyway to get the sorting goodness without loosing the binary indexes ? One solution I found is using RAW(16) to represent UUIDs, in that case Oracle will use the binary indexes regardless of the NLS sort/comp. But I was hoping there was a better alternative.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
能再描述一下环境吗？
如果您在同一列中存储不同的语言，那么任何形式的语言排序都会受到阻碍（即您混合使用法语和德语，您是按“法语”顺序还是“德语”顺序排序）？
另外，为什么使用 NVARCHAR ？如果默认使用多字节字符集，则 VARCHAR 将存储任何必要的字符。
RAW(16) 显然比 CHAR(36) 小很多，并且更接近 UUID 的“本机”格式（尽管数字也可以工作）。十六进制形式更多的是一个演示问题，而不是我用作 PK 的东西（特别是包括连字符）。我可能会将其派生为 11gR2 中的视图或虚拟（派生）列。
特别是在多语言应用程序中，将 UUID 存储在 CHAR 中时存在字符集转换的风险。我什至不确定 UUID 在韩语或中文中应该是什么样子，其中“a”、“b”和“c”等字母不是本地字母。
Can you describe the environment a bit more.
If you are storing different languages in the same column, then any form of linguistic sorting is going to be hampered (ie you have a mix of French and German, do you sort in the 'French' order or 'German' order) ?
Also, why use NVARCHARs ? If you have a multi-byte characterset as the default, then VARCHAR will store any necessary characters.
A RAW(16) is obviously a lot smaller than a CHAR(36), and is much closer to the 'native' format of a UUID (though a number could also work). The hex form is more a presentation issue, and isn't something I'd use as a PK (especially including the hyphens). I MIGHT derive it a view or virtual (derived) column in 11gR2.
Especially in a multi-lingual application, there's the risk of character set translation when storing a UUID in a CHAR. I'm not even sure how a UUID should look in Korean or Chinese where letters like 'a','b' and 'c' aren't native.
如果您为每个会话设置 NLS_SORT 和 NLS_COMP，您真的需要索引来使用默认排序吗？您可以创建一个基于函数的索引 实现了语言排序？
If you are setting the NLS_SORT and NLS_COMP for every session, do you really need the indexes to use the default sorting? Could you create a function-based index instead that implemented the linguistic sorting?