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

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

---

SQL 대소 문자를 구분합니다. 대소 문자를 구분하지 않는 것으로 보이는 MySQL과 SQL Server를 사용했습니다. 항상 그런가요? 표준은 대소 문자 구분을 정의합니까?

---

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

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

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

---

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

---

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

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

---

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

SQL-92 초 참조 . 5.2

---

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 등)에서 사례가 일관성이 있는지 확인해야합니다.

---

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

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

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

SELECT fieldName
FROM tableName;

tablename 에서 fieldname 을 쿼리 하지만

SELECT "fieldName"
FROM "tableName";

tableName 에서 fieldName 을 쿼리 합니다.

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

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

My convention when I used Oracle on a daily basis was that in code I would put all Oracle SQL keywords in uppercase and all identifiers in lowercase. In documentation I would put all table and column names in uppercase. It was very convenient and readable to be able to do this (although sometimes a pain to type so many capitals in code -- I'm sure I could've found an editor feature to help, here).

In my opinion MySQL is particularly bad for differing about this on different platforms. We need to be able to dump databases on Windows and load them into UNIX, and doing so is a disaster if the installer on Windows forgot to put the RDBMS into case-sensitive mode. (To be fair, part of the reason this is a disaster is our coders made the bad decision, long ago, to rely on the case-sensitivity of MySQL on UNIX.) The people who wrote the Windows MySQL installer made it really convenient and Windows-like, and it was great to move toward giving people a checkbox to say "Would you like to turn on strict mode and make MySQL more standards-compliant?" But it is very convenient for MySQL to differ so signficantly from the standard, and then make matters worse by turning around and differing from its own de facto standard on different platforms. I'm sure that on differing Linux distributions this may be further compounded, as packagers for different distros probably have at times incorporated their own preferred MySQL configuration settings.

Here's another SO question that gets into discussing if case-sensitivity is desirable in an RDBMS.

---

No. MySQL is not case sensitive, and neither is the SQL standard. It's just common practice to write the commands upper-case.

Now, if you are talking about table/column names, then yes they are, but not the commands themselves.

So

SELECT * FROM foo;

is the same as

select * from foo;

but not the same as

select * from FOO;

---

I found this blog post to be very helpful (I am not the author). Summarizing (please read, though):

...delimited identifiers are case sensitive ("table_name" != "Table_Name"), while non quoted identifiers are not, and are transformed to upper case (table_name => TABLE_NAME).

He found DB2, Oracle and Interbase/Firebird are 100% compliant:

PostgreSQL ... lowercases every unquoted identifier, instead of uppercasing it. MySQL ... file system dependent. SQLite and SQL Server ... case of the table and field names are preserved on creation, but they are completely ignored afterwards.

---

SQL keywords are case insensitive themselves.

Names of tables, columns etc, have a case sensitivity which is database dependent - you should probably assume that they are case sensitive unless you know otherwise (In many databases they aren't though; in MySQL table names are SOMETIMES case sensitive but most other names are not).

Comparing data using =, >, < etc, has a case awareness which is dependent on the collation settings which are in use on the individual database, table or even column in question. It's normal however, to keep collation fairly consistent within a database. We have a few columns which need to store case-sensitive values; they have a collation specifically set.

---

I don't think SQL Server is case-sensitive, at least not by default.

When I'm querying manually via Management Studio, I mess up case all the time and it cheerfully accepts it:

select cOL1, col2 FrOM taBLeName WheRE ...

참고URL : https://stackoverflow.com/questions/153944/is-sql-syntax-case-sensitive