Home Page for the TeradataForum
 
https:

Archives of the TeradataForum

Message Posted: Mon, 12 Feb 2007 @ 13:06:57 GMT


     
  <Prev Next>   <<First <Prev Next> Last>>  


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



     
  <Prev Next>   <<First <Prev Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 28 Jun 2020