Ответ 1

Это не является технической проблемой для базы данных, которая имеет заглавные буквы в именах таблиц или столбцов, для любого механизма БД, о котором я знаю. Имейте в виду, что во многих реализациях БД используются имена, чувствительные к регистру, поэтому всегда обращайтесь к таблицам и столбцам, используя тот же случай, с которым они были созданы (я говорю очень часто, так как вы не указали конкретную реализацию).

Для MySQL здесь представлена ​​интересная информация о том, как она обрабатывает регистр. Есть несколько вариантов, которые вы можете установить, чтобы определить, как они хранятся внутри. http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

Ответ 2

В стандарте SQL-92 указано, что идентификаторы и ключевые слова не чувствительны к регистру (в руководстве A для 4-го издания SQL Standard, Date/Darwen)

Чтобы не сказать, что конкретная СУБД не является (1) сломанной или (2) настраиваемой (и сломанной)

С точки зрения стиля программирования я предлагаю использовать разные случаи для ключевых слов и идентификаторов. Лично мне нравятся идентификаторы верхнего регистра и ключевые слова нижнего регистра, потому что он выделяет данные, которые вы манипулируете.

Ответ 3

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

SELECT column_a, column_b FROM table_name WHERE column_a = 'test'

Ответ 4

Насколько я знаю для обычного L.A.M.P. настройка не имеет значения - но имейте в виду, что MySQL, размещенный на Linux, чувствителен к регистру!

Чтобы мой код был аккуратным, я обычно придерживаюсь имен нижних регистров для таблиц и колонок, прописных MySQL-кодов и смешанных переменных верхнего-нижнего регистра - вот так:

SELECT * FROM my_table WHERE id = '$ myNewID'

Ответ 5

Я использую pascal case для имен полей в нижнем регистре для имен таблиц (обычно) следующим образом:

students
--------
ID
FirstName
LastName
Email
HomeAddress

courses
-------
ID
Name
Code
[etc]

Почему это круто? потому что он читаем, и потому что я могу его проанализировать как:

echo preg_replace('/([a-z])([A-Z])/','$1 $2',$field); //insert a space

СЕЙЧАС, вот забавная часть для таблиц:

StudentsCourses
--------------
Students_ID
Courses_ID
AcademicYear
Semester

Обратите внимание, что я использовал буквы S и C? Таким образом, они обращаются к первичной таблице (таблицам). Вы даже можете написать процедуру для логического анализа структуры db таким образом и автоматически создавать запросы. Поэтому я использую кепки в таблицах, когда они являются таблицами JOIN, как в этом случае.

Аналогично, подумайте о _ как a → в этой таблице как: Students- > ID и Courses- > ID Not student_id - вместо Students_ID - родственное поле соответствует точному имени таблицы.

Использование этих простых соглашений дает читаемый протокол, который обрабатывает около 70% вашей типичной реляционной структуры.

Ответ 6

Если вы используете postgresql и PHP, например, вам нужно написать свой запрос следующим образом:

$sql =  "SELECT somecolumn FROM \"MyMixedCaseTable\" where somerow= '$somevar'";

"Цитирование идентификатора также делает его чувствительным к регистру, в то время как неупомянутые имена всегда сворачиваются в нижний регистр. Например, идентификаторы FOO, foo и" foo "считаются одинаковыми по PostgreSQL, но" Foo "и" FOO "отличаются от этих трех и друг от друга (сворачивание некотируемых имен в нижний регистр в PostgreSQL несовместимо со стандартом SQL, в котором говорится, что некотируемые имена должны быть свернуты в верхний регистр. Таким образом, foo должен быть эквивалентен" FOO "не" foo "в соответствии со стандартом. Если вы хотите писать переносные приложения, вам рекомендуется всегда указывать конкретное имя или никогда не процитировать его.)" http://www.postgresql.org/docs/8.4/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

Итак, иногда это зависит от того, что вы делаете...

Ответ 7

Стандарт SQL требует, чтобы имена хранились в верхнем регистре

Стандарт SQL требует, чтобы идентификаторы сохранялись во всех верхних регистрах. См. Раздел 5.2.13 SQL-92, приведенный в черновом тексте в этом ответе по другому вопросу. Стандарт позволяет использовать индексированные идентификаторы в нижнем регистре или в смешанном случае, так как SQL-процессор требуется для преобразования по мере необходимости для преобразования в верхнюю регистрационную версию.

Это требование, предположительно, относится к ранним дням SQL, когда системы мейнфреймов были ограничены только прописными английскими символами.

Non-вопрос

Многие базы данных игнорируют это требование по стандарту. Postgres, в частности, делает как раз наоборот, преобразовывая все некотируемые ( "неуправляемые" ) идентификаторы в нижний регистр - это несмотря на то, что Postgres в противном случае приближается к стандарту, чем любая другая система, о которой я знаю. Некоторые базы данных могут хранить идентификатор в указанном вами случае.

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

Есть случайные случайные случаи, когда вам может потребоваться указать идентификатор в его сохраненном случае, или вам может потребоваться указать все в верхнем регистре. Это может случиться с некоторыми утилитами, где вы должны передать идентификатор в виде строки вне обычного контекста SQL-процессора. Редкий, но уберите это в затылок, если вы когда-нибудь столкнетесь с каким-то загадочным сообщением об ошибке "не можете найти стол", когда используете какой-то необычный инструмент/утилиту. Однажды случилось со мной.

Случай змеи

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

Использование подчеркивания, а не Случай верблюда помогает, если ваши идентификаторы когда-либо представлены как все прописные (или все строчные буквы) и тем самым теряют удобочитаемость без разделения слов.

Бонусный совет: стандарт SQL (раздел 5.2.11 SQL-92) явно promises никогда не будет использовать конечное подчеркивание в ключевом слове. Поэтому добавьте заключительный знак подчеркивания ко всем вашим идентификаторам, чтобы устранить все беспокойства о случайном столкновении.

Ответ 8

Никакая современная база данных не может обрабатывать текст в верхнем или нижнем регистре.

Ответ 9

Независимо от того, что вы используете, имейте в виду, что MySQL на Linux чувствителен к регистру, в то время как в Windows он нечувствителен к регистру.