Допустим, у меня есть база данных, полная музыкальных исполнителей. Обратите внимание на следующих художников:
The Beatles — «The» официально является частью названия, но мы не хотим сортировать его по буквам «T», если мы располагаем по алфавиту. Мы не можем легко сохранить его как «Beatles, The», потому что тогда мы не сможем правильно его найти.
Бейонсе. Нам нужно предоставить пользователю возможность искать «Бейонсе» (без диакритического знака) и получать правильные результаты. Ни один пользователь не будет знать, как или тратить время на ввод специального диакритического символа после последней «е» при поиске, но мы, очевидно, хотим правильно отображать его, когда нам нужно его вывести.
Каков наилучший способ обойти эти проблемы? Кажется расточительным хранить в базе данных «официальное имя», «имя для поиска» и «имя сортировки», поскольку очень большое большинство записей будет точно таким же, но я не могу придумать никаких других вариантов..
Решение проблемы
У специалистов по библиотечному делу есть стандартный ответ на этот вопрос. Правила подачи документов ALA охватывают все эти случаи совершенно стандартным образом.
Вы говорите о грамматическом порядке сортировки. Это дискуссионная тема. Некоторые люди не согласились бы с вашей позицией.
Как правило, вы преобразуете название в нормализованную форму: «Beatles, The». В общем, так и оставляешь. Потом сортировать.
Вы можете прочитать о правилах каталогизации здесь: http://en.wikipedia.org/wiki/Library_catalog#Cataloging_rules
Для «расширенных» персонажей у вас есть несколько вариантов. Для некоторых людей é — это первоклассная буква, и диакритические знаки являются ее частью. Они не смущены. Для других людей все диакритические символы отображаются на неукрашенные символы. Это сопоставление является функцией некоторых инструментов обработки Unicode.
Вы можете прочитать об удалении диакритических знаков Unicode здесь: http://lexsrv3.nlm.nih.gov/SPECIALIST/Projects/lvg/current/docs/designDoc/UDF/unicode/NormOperations/stripDiacritics.html
http://www.siao2.com/2005/02/19/376617.aspx
Комментариев нет:
Отправить комментарий