Какие проблемы следует ожидать, чтобы иметь разные сопоставления между разработкой и производством SQL Server?

Question

Подзапрос «Невозможно обновить sys.columns - любой другой подход?» смутно упоминаются проблемы при развертывании на сервер с другим сопоставлением.

Проблема в том, что по умолчанию параметры сортировки SQL Server определяются (во время установки) с помощью региональных и языковых параметров Windows -> Дополнительно -> "Выберите язык, соответствующий языковой версии не-Unicode-программы, которую вы хотите использовать "в панели управления.

Таким образом, эта разница в сопоставлениях между dev и производственными / клиентскими SQL-серверами является довольно распространенной ситуацией.
Например, но только для примера, у меня есть сортировка Cyrillic_General_CI_AS, пришедшая из Windows на мой локальный SQL Server, и у меня есть клиенты, имеющие серверы с сортировкой на иврите.

Итак, какие проблемы / проблемы должны возникнуть у разработчика для разработки с одним сопоставлением и, возможно, иногда даже не зная, какое сопоставление имеет клиент / клиент на SQL Server?

Обновление:

Допустим, типичная ситуация заключается в том, что я не занимаюсь разработкой базы данных с нуля или установкой производственного SQL Server на клиенте. Типичная ситуация заключается в том, что я либо подключаюсь к SQL Server, либо выполняю его на общем или выделенном сервере и / или получаю резервную копию базы данных.

Update2:
@ u07ch
Мой компьютер работает под управлением Windows XP Pro SP3 (на английском языке) и SQL Server на английском языке (на английском языке).
Пожалуйста, посмотрите на мой вопрос, откуда происходит сопоставление SQL Server по умолчанию («Выберите язык, соответствующий языковой версии не-Unicode-программы, которую вы хотите использовать»).

Я не мог понять, как «никогда не использовать временные таблицы или что-то еще, что использует TEMPd».
TempDB используется для большинства операций в SQL Server, даже для хранения промежуточных результатов выбора.

@ Damien_The_Unbeliever
Я не чувствую, что CS_AS неловко. ПО МОЕМУ МНЕНИЮ. это CI-AI, что неудобно.

Если выполнить скрипт (вручную или с помощью SSMS), то я неизбежно столкнусь с Параметры сортировки составляются из сценариев либо для всех столбцов, либо без них

Update3:
Мой вопрос явно говорит, и мои обновления повторяют, что я НЕ в любом случае использую любые кириллические сопоставления (или даже кодовые страницы), но мой SQL Server и базы данных имеют Cyrillic_General_CI_AS в качестве сопоставления по умолчанию из-за настройки SQL Server по умолчанию, связанной с зависимости от конфигурации Windows.
Обоснование этому, кстати, трудно объяснить или понять, но это просто статус-кво в установках SQL Server ...
Но результат заключается в том, что эта зависимость практически обеспечивает разную (по умолчанию) сортировку SQL-серверов в разных странах. В чем суть этого вопроса ...

Answer 1

Если у ваших клиентов еще нет SQL-сервера на иврите, и вы устанавливаете его с нуля, то параметры сортировки SQL Server настраиваются администратором базы данных во время установки путем выбора пользовательской опции установки;в конечном итоге вы попадаете на вкладку конструктора сличений в 2005/08 году.

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

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

Answer 2

Если вы знаете, что будете иметь дело с различными параметрами сортировки, то лучший совет, который я услышал, - убедиться, что параметры сортировки, с которыми вы работаете, настолько неловки, насколько это возможно.Поэтому я бы изменил вашу настройку разработки, чтобы использовать, как минимум, чувствительный к регистру и чувствительный к акценту порядок сортировки (CS_AS, а не CI_AS).

Таким образом, любые предположения, связанные с сопоставлением, которые вы делаете в коде,показывать в разработке, а не при выпуске в производство.

Я бы также позаботился о том, чтобы любые сценарии были написаны от руки (или вы отключили параметры сценариев в SSMS, которые включают параметры сортировки) и любые выпуски дляпроизводство выполняется по сценарию, а не, например, с помощью мастера импорта / экспорта или путем восстановления баз данных.Таким образом, производственная база данных должна иметь параметры сортировки, требуемые конечными пользователями.