"Внутренние компоненты SQL Server 2008" хорошо обсуждают тему imho.
Двоичное сопоставление сложно, если вы намерены поддерживать текстовый поиск людей, лучше использовать недвоичный. Двоичный код хорош для небольшого увеличения производительности, если вы настроили все остальное (сначала архитектура) и в тех случаях, когда чувствительность к регистру и акцент чувствительны, например, хэши паролей. Двоичное сопоставление на самом деле является «более точным» в том смысле, что оно не учитывает похожие тексты. Хотя порядок сортировки, который вы получаете, хорош только для машин.
Существует лишь небольшая разница между сопоставлениями SQL_ * и родными окнами. Если вы не ограничены совместимостью, переходите к нативным, так как они еще впереди.
Сортировка решает порядок сортировки и равенство. Вы выбираете, что действительно лучше всего подходит вашим пользователям. Понятно, что вы будете использовать типы юникода (например, nvarchar) для своих данных для поддержки международного текста. Сортировка влияет на то, что может храниться в столбце, не поддерживающем юникод, и не влияет на вас.
Что действительно важно, так это то, что вы избегаете смешивать параметры сортировки в предложении WHERE, потому что именно здесь вы платите штраф, не используя индексы. Afaik нет сортировки серебряной пули для поддержки всех языков. Вы можете выбрать один из них для большинства своих пользователей или перейти к поддержке локализации с разными столбцами для каждого языка.
Одна важная вещь состоит в том, чтобы параметры сортировки сервера совпадали с параметрами сортировки базы данных. Это сделает вашу жизнь намного проще, если вы планируете использовать временные таблицы в качестве временных таблиц, если они созданы с помощью «CREATE TABLE #ttt ...», подбирают параметры сортировки сервера, и вы столкнетесь с конфликтами параметров сортировки, которые вам нужно будет решить с помощью указание явного сопоставления. Это также влияет на производительность.