Евгений_СТПравда, я не совсем понял, при чём тут индекс по текстовому полю? Вы хотите сказать, что я должен хранить в полях своей БД только англо-язычные текстовые строки, поскольку они индексируются быстрее русско-язычных?
Когда итальянцы пытались нам впарить свою систему планирования производства, случился показательный конфуз. В их БД (БД типовая - сделанная по скрипту Data Model Resource Ливингстоуна) была построена иерархическая структура хранения данных об изделиях и их составе (сильно упрощенно: изделие А входит в состав изделия Б, изделие Б входит в став изделия В... и так далее). Первичным ключем при этом был индекс самого изделия. Ессно, мы попросили их ввести парочку реальных изделий нашей номенклатуры - и изделия эти были успешно введены. Однако, они не находились поиском, а попытка провести их деталировку выдавала букет ошибок. (Я подсунула именно те изделия, которые помимо цифровой части содержали один модификатор - букву "П" - "поддон")

После этого они не стали спрашивать у моего программиста "а при чем тут индекс по текстовому полю" - сообразили сами. В тот же день изменили тип данных и вечером повторили демонстрацию. Но быстродействие системы упало в несколько раз. Они уехали к себе и потратили два месяца, чтобы устранить эту недоработку, использовав в качестве первичного ключа не индекс изделия, а 36-разрядный текстовый счетчик от "00000001" до "ZZZZZZZZ" (да-да, фиксированной длины - 8 символов ;)) ). Сколько им для этого пришлось перелопатить - страшно представить.

Но момент они упустили - мы за это время успели нормально сформулировать четкие требования к консалтингу, т.к. вышли из цейтнота, в который были поставлены неразберихой на предварительных переговорах. И внедрение ПО отошло на задний план.

Я не знаю, сколько они на этом потеряли (за денежную сторону вопроса в таких случаях отвечаю не я), но предпологаю, что очень много. Их главного разработчика ПО на последующих переговорах я уже не видела. Подозреваю, что он был назначен крайним и с ним обошлись неласково, хотя, если смотреть в корень, крайним является американец Ливингстоун, которого не особо волновали информационные системы на русском или суахили, и главный разработчик SQL Server, не имею чести знать его ФИО...

авторЕсли я приду к выводу, что показатели производительности меня не устраивают, то я просто подберу такую аппаратно-программную конфигурацию, которая будет обеспечивать требуемую производительность
Любой человек волен ходить по канату без страховки или по стройке - без каски... Любой человек волен выполнять свою работу, не думая заранее о грядущих проблемах или отмахиваясь от них... Более того! Огромное количество людей именно этим периодически и занимается!
И меня это радует - если б этого не было, то моя работа системного аналитика была б никому не нужна. :))

Евгений_СТИ особо непонятно вот это ваше утверждение: "(раз уж использование числового типа данных по к.-л. причинам невозможно)". Вы используете в ваших БД числовые типы данных вместо строковых? То есть в справочниках вы вместо названий сущностей применяете только их коды? И пользователи вашей программы вводят цифры вместо названий предприятий и товаров, а расшифровка этих цифр производится с помощью бумажной распечатки, лежащей рядом с компьютером? Очень оригинальный подход.

Я говорю об ID в таблицах, а уж почему вы под этим понимаете Description - судить не берусь, ибо как вы верно заметили - негоже пытаться думать за других...

Евгений_СТ КомсомолкаЯ говорю об ID в таблицах, а уж почему вы под этим понимаете Description - судить не берусь, ибо как вы верно заметили - негоже пытаться думать за других...

Цитирую ваши слова: "каким должно быть текстовое поле, чтобы индекс по нему... ? ". В данном случае мне не нужно было думать за вас, ибо вы говорили о "текстовом поле", а не о "ключевом".
Тему топика прочтите, а...

Евгений_СТВ любом случае, открытым остаётся вопрос - каким образом имя поля, названное не латинскими, а кириллическими буквами, повлияет на скорость сортировки?
Как прикладник-экстремал вы можете еще использовать пробелы и спецсимволы... На быстродействие - нет, ощутимо влиять не будет (и то - не факт). Но повлияет на общую надежность и ремонтабельность. Вас, как любителя переключать раскладки с русского на латинский и обратно, конечно же не напряжет такая мелочь, как постоянная необходимость вводить квадратные скобки или кавычки (что у вас там? T-SQL?). Ну, так я уже говорила - есть люди, которые придумывают себе лишнюю никому (кроме них) ненужную работу и это нормально - иногда за иммитацию работы тоже неплохо платят.

Исходя из собственного опыта работы с программистами - подобные взгляды озвучивают низкопрофессиональные программисты-одиночки, мало озабоченные тем, что их маленькие приложения будут частью некой бОльшей системы. Понятно, что в последнюю очередь они задумывались о развитии этих приложений, предпочитая решать проблемы по мере их поступления.

Кстати, я понимаю человеческую реакцию до последнего держаться за свое убеждение, даже если против одного довода "за" (понятность кирилицы для низкообразованных коллег) приводятся несколько весомых доводов "против". Так что пишите еще. :))

Я еще раз повторяю, что собственноручное раскладывания грабель для себя-любимой не относится к моим многочисленным хобби, так что вряд ли мы придем к взаимопониманию.

P.S. Если не секрет, вы случайно не 1С-программистом раньше работали?