 |
 |
Archives of the TeradataForum
Message Posted: Mon, 12 Feb 2007 @ 13:06:57 GMT
| Subj: | | Re: Accent Insensitive Matches |
| |
| From: | | Victor Sokovin |
| | This looks like an interesting alternative, but I'm not quite sure that I understand what you mean. The multinational collation already
groups accented characters together, but I guess that internally these characters still have a distinct rank (they are just ordered differently
than in, say, the ASCII collation). | |
| | Are you suggesting to create my own collation but assign the same ranks to each accented character? Is this possible? Even if it is, would
it be possible then to change the collation depending on the query run? For example, my own collation would be useful when I compare strings, but
the multinational collation would be better when I want to order these strings. | |
| | In other words, when I compare strings, it's okay for "e acute" to be equal to "e", but when I order them, I definitely want "e acute" to
always come before or after "e". | |
Mario, you can specify collation for each query and switch between standard MULTINATIONAL and non-standard collation you define for yourself.
By the way, I would not create the first non-standard collation from the MULTINATIONAL as it is a bit special and exceptional. There are always
other collations to play with such as Swedish or Norwegian, for example. It is fairly certain that nobody uses them and you can take them as
prototypes. Even if somebody uses them you just create your own version anyway.
| | This is kind of scary! :) It would involve writing an extremely complex set of queries that could take forever to run. I guess that
spooling out data and finish with a client-side process is, at this point, the only practical solution in my situation. However, I will keep you
posted. Maybe my support group will respond in a timely manner and allow me to use my own UDFs or collations so I can use a more efficient
server-side solution. | |
No, that would not take anything "extremely complex" (esthetically non-pleasing at the most) and the queries would not be much slower than the
ones with UDF. You surely do not expect a few lines of C in the UDF (and that's what they are) to compete with the internal conversion routines
already present in the database, don't you? And you can be smart and selective and only convert when there is something to convert, etc.
Regards,
Victor
| |
