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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

SELECT this, that FROM Table;

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

Answer 7

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

Answer 8

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