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

Мы просто "перенесли" базу данных SQL Server 2005 с DEVEL в TEST. Каким-то образом во время процесса миграции БД было изменено с нечувствительного к регистру на чувствительное - поэтому большинство SQL-запросов разразились эффектно.

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

ПРИМЕЧАНИЕ. Под этим я подразумеваю имена таблиц, имена столбцов, сохраненные имена процессов и т.д. Я НЕ отношусь к фактическим данным, хранящимся в таблицах.

При первой проверке я не могу найти допустимую причину, которая дает преимущества по сравнению с нечувствительностью к регистру.

Ответ 1

Я только узнал, почему мы делаем его чувствительным к регистру. Это необходимо, чтобы при развертывании на клиентском сайте наша БД работала независимо от того, настроен ли клиентский SQL Server с учетом регистра или нет.

Это один ответ, которого я не ожидал.

Ответ 2

Я действительно не могу придумать какой-либо хорошей причины. Идентификаторы SQL должны быть чувствительны к регистру. Я могу придумать один плохой, один из которых MySQL дает для почему имена их таблиц чувствительны к регистру. Каждая таблица представляет собой файл на диске, ваша файловая система чувствительна к регистру, а разработчики MySQL забывают table_file = lc(table_name). Это куча удовольствия, когда вы перемещаете схему MySQL в файловую систему без регистра.

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

Некоторый автор схемы будет умным и решит, что this_table, очевидно, означает нечто отличное от this_table и делает эти две таблицы (или столбцы). Вы также можете написать "вставить ошибки здесь" в этот момент в схеме.

Кроме того, нечувствительность к регистру позволяет вам быть более выразительными в вашем SQL, чтобы подчеркнуть таблицы и столбцы против команд, не считаясь с тем, что решил автор схемы.

SELECT this, that FROM Table;

Ответ 3

Не все разделы Юникода имеют биективное отображение между символами верхнего и нижнего регистра - или даже два набора случаев.

В этих регионах "нечувствительность к регистру" немного бессмысленна и, вероятно, вводит в заблуждение.

Что обо всем, о чем я могу думать сейчас; в наборе ASCII, если вы не хотите, чтобы Foo и foo были разными, я не вижу смысла.

Ответ 4

В большинстве языков есть чувствительные к регистру, как и большинство алгоритмов сравнения, большинство файловых систем и т.д. Нечувствительность к регистру для ленивых пользователей. Хотя это, как правило, упрощает ввод типов и приводит ко многим вариантам одинаковых имен, отличающихся только случаем.

Лично, между (MyTable, mytable, myTable, MYTABLE, MYTable, myTABLE, MyTaBlE), мне бы хотелось увидеть одну универсальную версию.

Ответ 5

Мне нравится чувствительность к регистру, главным образом потому, что я привык к программированию на Perl (и даже на любом другом языке). Мне нравится использовать StudlyCaps для имен таблиц и всего нижнего регистра с символами подчеркивания для столбцов.

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

Ответ 6

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

Вообще говоря, мне легче работать с базами данных, где нет возможности, что идентификаторы, id и Id являются отдельными полями.

Помимо личного предпочтения в отношении пыток, я настоятельно рекомендую вам оставаться с нечувствительностью к делу.

Единственная база данных, с которой я когда-либо работал, была настроена для чувствительности к регистру, была Great Plains. Мне показалось, что нужно помнить, что каждая отдельная оболочка их имен схем была болезненной. У меня не было привилегии работать с более поздними версиями.

Если это не изменилось, и если моя память служит, характер чувствительности к регистру, о котором вы говорите, определяется во время установки и применяется ко всем базам данных. Это было в случае с установкой SQL Server, в которой работала база данных Great Plains, я упомянул, что все базы данных на этой установке чувствительны к регистру.

Ответ 7

Я поддерживаю Sybase Advantage Database Server и использует плоский формат файла, позволяющий DBF, а также собственный собственный формат ADT. Случай, когда я вижу, что чувствительность к регистру является проблемой, - это использование нашей Linux-версии сервера. Linux - это ОС, чувствительный к регистру, поэтому у нас есть опция в нашем db для ввода всех вызовов. Это требует, чтобы файлы таблиц были в нижнем регистре.

Ответ 8

Я уверен, что SQL Spec требует свертывания кода (что фактически так же, как и нечувствительность) для идентификаторов. PostgreSQL сбрасывает нижнюю границу, ORACLE складывается в верхнюю.