>>Anyway, if it's just for sorting purposes,

>>    index on first +second tag whatever

>>would simply be the best. For display purposes, then, we could combine them like in previous attempts.
>
>I think you meant second + first (as in Nedeljkovic + Dragan?)? If so, I agree.

There's a general lack of consensus of what is "name" and what is "other name", and which is the person's name and which is the family name. AFAIK, the family-name-first is usual in Chinese and Hungarian languages only (though I have heard this list is somewhat wrong - would like to be updated), while all others go the other way 'round - except in alphabetical listings. In this example "first" was meant as "the one you want to go first".

>What I've decided to do is let the user specify the sort order by having a field just for that purpose. She types "The Richmond Family" in one field, then, using InteractiveChange, I set the sortname field to "Richmond Family, The". I think that most of the time my algorithm will give the correct results, but the user can change it if desired. For example, my algorithm wouldn't handle my own situation, where the family name is "Mark Wilden and Kate Smith" (my wife kept her maiden name).

My wife keeps both names, so she's my test for name fields - if it fits (31 chars altogether, including the hyphen), the field is long enough. I like your approach, though it surely must have its limitations on what it can do while guessing a good default - remember the thread on proper capitalization of names few months ago. The only thing we were sure of is that there's no bulletproof rule to rely on; we can only hope for a list of exceptions.

On the issue of names to sort by, I've generally had two approaches: one is to tell the users that the field will be used to incrementally search by (demonstrating it right on using the ZIP codes table), and that they'd take care not to put any quotes around the customers' company names, not to put any abbreviations in the start (equivalents of LTD, INC and such naturally come before the name in my language).

The other approach, used in phone book only so far, was to supply a list of keywords to search by, and store them into a separate table, which has only the master table's FK and the keyword, indexed by keyword. The keywords may be repeated at will, and are also stored in a memo field in the master table (though this may not be necessary, it made my life easier). During input, I fill the keywords memo with all the words from the previous fields, and allow user to remove and add any words they like. Then, when searching for a phone number, they may search by nicknames, or type of the shop, or street or whatever they like. I've seen them extracting pharmacies from a 3000 entries table within seconds, without the need to specifically dedicate a field to "shop type" - there are also many entries where this field would be empty.