Re: Localization or an other solution

Followup on my own message.

I just paused for a second and realized you couldn't
do straight sorting, since then all text would be handled
that way.

It seems the only way external functions could be used
to help you out would be to write a turkishhash
function which assigns a value to all strings, based on
their alphabetic order, in Turkish. Then you could
sort the results of a query with something like this:

select username from testtable order by turkishhash(username);

You would get into trouble with long strings and large
tables, as they received the same hash value. The
solution might be better than nothing, though.

Troy

>
> Hi,
> As everybody knows, or at least guess, the Turkish-specific characters
> is ordered incorrectly unless you don't have localization support. (For
> example there is a letter like 's' but has a dot under it; this letter
> must come after 's'; without localization support this and other
> non-English ones come after 'z' )
> According to the manual, localization causes the loose of performance.
> Beside, I scare to use localization which is not familiar to me. Because
> of these, I try to find an other solution. The one that I think on is
> - to use a seperate field for each of the fields that I want to order;
> - to put a correctly-sortable version of the data in the related field
> - and to use this extra fields for sorting purposes.
> Example:
> Original data: 'imek'
> In extra field: 'szzimszzek'
> Finally, my question is:
> In a table which has 100.000 or more records, which one will be more
> faster? Localization or this one.
> Thanks in advance
> Erol Oz
>
>