我的表使用UUID作为主键，并将它们作为CHAR（36）存储在Oracle DB中。大多数表包含可以使用任何语言的NVARCHAR列。我想在这些列上支持自然语言排序，我通过在oracle会话上设置NLS_SORT和NLS_COMP（通过ALTER SESSION）来实现。我遇到的问题是oracle不会在UUID列上使用二进制索引，并且总是进行全表扫描。
无论如何在不丢失二进制索引的情况下获得排序优势？我找到的一个解决方案是使用RAW（16）来表示UUID，在这种情况下，Oracle将使用二进制索引而不管NLS sort / comp。但我希望有更好的选择。
有什么建议吗？
答案 0 :(得分：2)
你能描述一下环境吗？
如果您在同一列中存储不同的语言，那么任何形式的语言排序都会受到阻碍（即您混合使用法语和德语，您是按照“法语”顺序还是“德语”顺序排序）？
另外，为什么要使用NVARCHAR？如果您有一个多字节字符集作为默认字符集，那么VARCHAR将存储任何必要的字符。
RAW（16）显然比CHAR（36）小很多，并且更接近UUID的“原生”格式（尽管数字也可以工作）。十六进制形式更像是一个演示问题，并不是我用作PK的东西（特别是包括连字符）。我可能会在11gR2中派生出一个视图或虚拟（派生）列。
特别是在多语言应用程序中，在CHAR中存储UUID时存在字符集转换的风险。我甚至不确定UUID应该用韩语或中文看起来像'a'，'b'和'c'这样的字母不是原生的。
答案 1 :(得分：0)
如果您为每个会话设置NLS_SORT和NLS_COMP，您真的需要索引来使用默认排序吗？你能创建一个实现语言排序的function-based index instead吗？