Осложнения с базой данных SQL Server, имеющей другую сортировку, чем сервер по умолчанию?

Question

Мы находимся в процессе миграции баз данных со старого сервера SQL Server 2k EE с параметрами сортировки по умолчанию «Latin1_General_CI_AS» на новые серверы SQL Server 2005 и 2008 с параметрами сортировки по умолчанию «SQL_Latin1_General_CP1_CI_AS».Я не знаю международных символов, которые бы требовали Unicode, поэтому я знаю, что эти две кодовые страницы практически одинаковы для практических целей.

Основной администратор базы данных SQL Server непреклонен в том, что каждая отдельная база данных (большинство из которых построеныСторонние приложения) должны быть перестроены с использованием нового сопоставления, прежде чем он их перенесет.

Я знаю, что с тех пор, как в SQL Server 2000 появилась возможность устанавливать для отдельных баз данных сопоставление, отличное от значения по умолчанию. Но каковы реальные последствия работы со смешанными сопоставлениями? Одна статья от Microsoft , например, предлагает осложнения с общей базой данных tempdb (но можно ли ее легко избежать?).

И, что еще важнее, что мы могли бы сделать, чтобы избежать этих проблем, если нам нужно поддерживать несколько параметров сортировки на новых серверах?

Answer 1

Проблема, связанная с различными параметрами сортировки между сервером и базой данных, заключается в том, что, как уже упоминалось, временные таблицы будут по умолчанию создаваться с параметрами сортировки сервера.Это сделает любые сравнения в символьных полях между временной таблицей и обычной таблицей неудачными.Этого можно избежать разработчиками сторонних приложений, используя COLLATE database_default для символьных полей временных таблиц.

create table #Tmp(Col1 nvarchar(50) COLLATE database_default)

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

Answer 2

Хорошо, не самый лучший ответ, но

Вы спросили: «Каковы реальные последствия работы с разными сопоставлениями» Это может быть головная боль. Статья, которую вы упомянули в Microsoft, прибивает ее по голове. По моему личному опыту я столкнулся с этой проблемой, и это было нелегко избежать. Несоответствующие параметры сортировки будут появляться в незапланированных местах, если вы не будете хорошо тестировать.

Вы также спросили: «Что мы можем сделать, чтобы избежать этих проблем, если нам нужно поддерживать несколько параметров сортировки на новых серверах?» Ничто не приходит на ум, кроме как проверить, как сумасшедший.

Я действительно желаю вам удачи, это может быть распространенная и волосатая проблема, которую я бы никому не пожелал.

Answer 3

Мой ответ тоже не очень хороший, но:

у нас есть несколько серверов подписчиков, синхронизирующихся с нашей основной базой данных, и на некоторых из них есть параметры сортировки, которые не принадлежат издателю. При запуске репликации мы продолжаем получать это «приветственное сообщение» о том, что «поскольку параметры сортировки не идентичны, синхронизация может не завершиться успешно».

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

Ах: и в инструкциях T-SQl также есть проблема с заглавными и строчными буквами ... отметьте это здесь

@ Майкл и ваш администратор БД правы .... ограничьте риски и используйте уникальное сопоставление.