SQL 구문은 대소 문자를 구분합니까?


답변:


181

는 SQL 키워드는 대소 문자를 구분하지 (있다 SELECT, FROM, WHERE, 등),하지만 종종 모두 대문자로 작성됩니다. 그러나 일부 설정에서 테이블 및 열 이름은 대소 문자를 구분합니다. MySQL에는 활성화 / 비활성화하는 구성 옵션이 있습니다. 일반적으로 대소 문자를 구분하는 테이블 및 열 이름은 Linux MySQL의 기본값이고 대소 문자를 구분하지 않는 Windows의 기본값이지만, 설치 프로그램은 설치 중에 이에 대해 물었습니다. MSSQL의 경우 데이터베이스 데이터 정렬 설정의 기능입니다.

대소 문자 구분에 대한 MySQL 페이지 는 다음과 같습니다.

다음은 MSSQL의 데이터 정렬에 대한 MSDN기사입니다.


7
PostgreSQL과 같은 일부 시스템은 테이블 및 열 이름에서 대소 문자를 구분하지만 모든 이름을 소문자 나 대문자로 검색하여 숨기려고합니다. 이러한 시스템에서는 입력 한 정확한 이름을 찾을 수 있도록 테이블 이름을 "큰 따옴표"로 묶어야합니다.
Michael Ratanapintha

2
나는 항상 실제로 반대를 보았다, 그것은 단지 취향이다, 나는 동의 "하지만 종종 모두 대문자로 작성됩니다"
BlackTigerX

3
예를 들어 대 / 소문자 구분 데이터 정렬을 사용하여 MS Sql 서버를 설치 한 경우 데이터베이스에 대 / 소문자 구분 데이터 정렬이 있어도 테이블, 열, 변수 이름은 대 / 소문자를 구분합니다.
Vadym Stetsiak

3
@BlackTigerX-Oracle 매뉴얼에는 대문자로 쓰여진 키워드 (SELECT, FROM, WHERE 등)가 포함 된 모든 예제 SQL이 있지만 소문자로 표 및 열 이름이 있습니다.
J. Polfer

흠, 이것은 여전히 ​​mysql에 해당됩니까? 나는 mysql의 기본 설치가 있다고 생각했고 열 이름은 대소 문자를 구분하지 않습니다.
Kzqai

22

이것은 엄격하게 SQL 언어는 아니지만 SQL Server에서 데이터베이스 데이터 정렬이 대소 문자를 구분하면 모든 테이블 이름은 대소 문자를 구분합니다.


16

Sql Server에서는 옵션 입니다. 전원을 켜면 짜증이납니다.

MySql에 대해 잘 모르겠습니다.


MySql에서 대소 문자 구분은 켜거나 끌 수있는 옵션입니다. 파일 시스템이 대 / 소문자를 구분하는 경우 (기본값) Linux에서와 같이 무감각이 작동하지 않습니다. mysql 대소 문자를 구분하지 않고 Windows와 동일한 방식으로 작동하려면 Linux에서 대소 문자를 구분하지 않는 파일 시스템을 만들어야합니다 (= 적절하게). 특히 다른 모드에서 작업 한 후에는 켜거나 끄면 나쁜 결과를 초래할 수 있습니다.
Stefan Steiger

14

식별자와 예약어는 대소 문자를 구분하지 않아야하지만, 많은 사람들은 예약어에 대문자를 사용하고 식별자에 파스칼 대소 문자를 사용하는 규칙을 따릅니다.

SQL-92 초 참조 . 5.2


13

SQL92 사양 상태는 식별자를 인용, 또는 인용 부호가 될 수있다. 양쪽에 따옴표가 없으면 항상 대소 문자를 구분하지 않습니다 (예 :) table_name == TAble_nAmE.

그러나 인용 된 식별자는 대소 문자를 구분합니다 (예 :) "table_name" != "TAble_naME". 당신이 인용 사람과 unqouted 식별자를 비교하고자하는 경우 또한 사양에 따라 예를 들어, 다음 인용 부호로 둘러싸이지 않은 및 인용 부호로 둘러싸이지 않은 문자가 대문자로하는 경우 인용 식별자는, 같은 고려 될 수 TABLE_NAME == "TABLE_NAME"있지만, TABLE_NAME != "table_name"TABLE_NAME != "TAble_NaMe".

다음은 스펙의 관련 부분입니다 (섹션 5.2.13).

     13)A <regular identifier> and a <delimited identifier> are equiva-
        lent if the <identifier body> of the <regular identifier> (with
        every letter that is a lower-case letter replaced by the equiva-
        lent upper-case letter or letters) and the <delimited identifier
        body> of the <delimited identifier> (with all occurrences of
        <quote> replaced by <quote symbol> and all occurrences of <dou-
        blequote symbol> replaced by <double quote>), considered as
        the repetition of a <character string literal> that specifies a
        <character set specification> of SQL_TEXT and an implementation-
        defined collation that is sensitive to case, compare equally
        according to the comparison rules in Subclause 8.2, "<comparison
        predicate>".

SQL 표준의 다른 부분과 마찬가지로 모든 데이터베이스가이 섹션을 완전히 따르는 것은 아닙니다. 예를 들어 PostgreSQL은 인용되지 않은 모든 식별자를 대문자 대신 소문자로 저장하므로 table_name == "table_name"표준과 정확히 반대입니다. 또한 일부 데이터베이스는 항상 대소 문자를 구분하지 않거나 대소 문자를 구분하여 DB의 일부 설정에 의존하거나 일반적으로 파일 시스템이 대소 문자를 구분하는지 여부에 관계없이 시스템의 일부 속성에 의존합니다.

일부 데이터베이스 도구는 항상 인용 된 식별자를 보낼 수 있으므로 일부 도구에서 생성 된 쿼리 (Liquibase 또는 다른 DB 마이그레이션 도구에서 생성 된 CREATE TABLE 쿼리와 같은)와 손으로 만든 쿼리 (간단한 JDBC 선택과 같은)를 혼합하는 경우 응용 프로그램에서) 특히 인용 부호와 인용 부호가없는 식별자가 다른 데이터베이스 (DB2, PostgreSQL 등)에서 사례가 일관성이 있는지 확인해야합니다.


10

내 이해는 SQL 표준이 대소 문자를 구분하지 않는다는 것입니다. 그러나 데이터베이스가 표준을 완전히 준수한다고 생각하지 않습니다.

MySQL은 대소 문자를 구분하거나 구분하지 않는 테이블 이름에 대한 "엄격 모드"(MySQL을보다 표준에 적합하게 만드는 여러 설정 모음)의 일부로 구성 설정을 가지고 있습니다. 이 설정에 관계없이 열 이름은 여전히 ​​대소 문자를 구분하지 않지만 열 이름이 표시되는 방식에 영향을 미친다고 생각합니다. 이 설정은 RDBMS 인스턴스 내의 모든 데이터베이스에서 인스턴스 전체에 적용된다고 생각하지만, 오늘이를 확인하기 위해 조사하고 있습니다 (답이 '아니요').

나는 오라클이 이것을 훨씬 잘 처리하는 방법을 좋아합니다. 일반 SQL에서 테이블 및 열 이름과 같은 식별자는 대소 문자를 구분하지 않습니다. 그러나 어떤 이유로 명시적인 케이스를 얻으려면 식별자를 큰 따옴표로 묶을 수 있습니다 (Oracle SQL에서는 문자열 데이터를 묶는 데 사용되는 작은 따옴표와는 매우 다릅니다). 그래서:

SELECT fieldName
FROM tableName;

tablename 에서 fieldname 을 쿼리 하지만

SELECT "fieldName"
FROM "tableName";

tableName 에서 fieldName 을 쿼리 합니다.

이 메커니즘을 사용하여 공백이나 다른 비표준 문자를 식별자에 삽입 할 수도 있습니다.

이 상황에서 어떤 이유로 명시 적으로 테이블과 열 이름이 바람직하다고 생각되면 사용할 수 있지만 여전히주의해야 할 사항이었습니다.

Oracle을 매일 사용했을 때의 관례는 코드에서 모든 Oracle SQL 키워드를 대문자로하고 모든 식별자를 소문자로 넣는 것입니다. 문서에서 모든 테이블 및 열 이름을 대문자로 입력했습니다. 이 작업을 수행하는 것은 매우 편리하고 읽기 쉬웠습니다 (때때로 코드에 많은 수도를 입력하는 데 어려움이 있기는하지만 여기서 도움이되는 편집기 기능을 찾을 수있을 것입니다).

제 생각에 MySQL은 다른 플랫폼 에서이 점을 다르게하는 데 특히 나쁩니다. Windows에서 데이터베이스를 덤프하여 UNIX로로드 할 수 있어야하며, Windows의 설치 프로그램이 RDBMS를 대소 문자 구분 모드로 전환하는 것을 잊어 버린 경우 재앙이됩니다. (공평하게 말하면, 이것이 재난의 원인 중 일부는 우리 코더가 오래 전에 UNIX에서 MySQL의 대 / 소문자 구분에 의존하기 위해 잘못된 결정을 내렸기 때문입니다.) Windows MySQL 설치 프로그램을 작성한 사람들은 정말 편리하고 Windows와 비슷하며 사람들에게 "엄격 모드를 켜고 MySQL을보다 표준에 적합하게 만들겠습니까?"라는 확인란을 선택하는 것이 좋습니다. 그러나 MySQL이 표준과 크게 다르면 매우 편리합니다. 그런 다음 다른 플랫폼에서 자체 표준과 다르게 돌아가서 문제를 악화시킵니다. 다른 배포판 용 패키저가 때때로 자신이 선호하는 MySQL 구성 설정을 통합했기 때문에 다른 Linux 배포판에서는 이것이 더 복잡해질 수 있다고 확신합니다.

다음 은 RDBMS에서 대소 문자 구분이 바람직한 지에 대한 또 다른 SO 질문입니다.


5

아니요. MySQL은 대소 문자를 구분하지 않으며 SQL 표준도 아닙니다. 명령을 대문자로 쓰는 것이 일반적입니다.

이제 테이블 / 열 이름에 대해 이야기하고 있다면 명령 자체는 아닙니다.

그래서

SELECT * FROM foo;

와 같다

select * from foo;

그러나 같지 않다

select * from FOO;

2
대부분의 RDBMS에서 테이블 이름은 대소 문자를 구분하지 않습니다. 최소한 기본적으로는 아닙니다. 이 규칙에서 가장 두드러진 예외는 MySQL입니다.

4

이 블로그 게시물 이 매우 유용 하다는 것을 알았 습니다 (저는 저자가 아닙니다). 요약 (하지만 읽어보십시오) :

... 구분 식별자는 대소 문자를 구분하며 ( "table_name"! = "Table_Name") 인용되지 않은 식별자는 대문자가 아니며 대문자로 변환됩니다 (table_name => TABLE_NAME).

그는 DB2, Oracle 및 Interbase / Firebird가 100 %를 준수 함을 발견했습니다.

PostgreSQL ... 따옴표없는 모든 인용 부호를 대문자로 표시하지 않습니다. MySQL ... 파일 시스템에 따라 다릅니다. SQLite 및 SQL Server ... 테이블 및 필드 이름의 경우는 작성시 유지되지만 나중에 완전히 무시됩니다.


2

적어도 기본적으로 SQL Server가 대소 문자를 구분한다고 생각하지 않습니다.

Management Studio를 통해 수동으로 쿼리 할 때 항상 사례를 엉망으로하고 즐겁게 받아들입니다.

select cOL1, col2 FrOM taBLeName WheRE ...

2

SQL 키워드는 대소 문자를 구분하지 않습니다.

테이블, 열 등의 이름은 데이터베이스에 따라 대소 문자를 구분합니다. 달리 알지 않는 한 대소 문자를 구분한다고 가정해야합니다 (많은 데이터베이스에서는 그렇지 않지만 MySQL 테이블 이름은 대소 문자를 구분하지만 대부분은 다른 이름이 아닙니다).

=,>, <등을 사용하여 데이터를 비교하는 경우 개별 데이터베이스, 테이블 또는 해당 열에서 사용중인 데이터 정렬 설정에 따라 대소 문자를 구분합니다. 그러나 데이터베이스 내에서 데이터 정렬을 상당히 일관성있게 유지하는 것이 일반적입니다. 대소 문자를 구분하는 값을 저장해야하는 몇 개의 열이 있습니다. 데이터 정렬이 구체적으로 설정되어 있습니다.


0

두 세계를 최대한 활용하십시오

요즘에는 모든 SQL 문을 소문자로 작성할 수 있으며 형식을 지정 해야하는 경우 플러그인을 설치하십시오. 이것은 코드 편집기에 해당 플러그인이있는 경우에만 적용됩니다. VSCode 에는이를 수행 할 수있는 많은 확장이 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.