SQL Server 2005 데이터베이스를 DEVEL에서 TEST로 '마이그레이션'했습니다. 어떻게 든 마이그레이션 프로세스 중에 DB가 대소 문자를 구분하지 않도록 민감하게 변경되었습니다. 따라서 대부분의 SQL 쿼리가 훌륭하게 부러졌습니다.대소 문자를 구분하는 데이터베이스에는 이점이 있습니까?
제가 알고 싶습니다. 대소 문자를 구분하는 스키마가 있으면 분명한 이점이 있습니까?
참고 : 이것은 테이블 이름, 열 이름, 저장된 proc 이름 등을 의미합니다. 실제로 테이블에 저장되는 데이터는 언급하지 않습니다.
첫 번째 검사에서 대소 문자를 구분하지 않는 것 이상의 이점을 제공하는 유효한 이유를 찾을 수 없습니다.
나는 왜 우리가 대소 문자를 구분하는지 알아 냈습니다. 클라이언트 사이트에 배포 할 때 DB는 클라이언트의 SQL Server가 대/소문자를 구분하는지 여부에 관계없이 작동합니다.
내가 예상하지 못했던 한 가지 답변입니다.
유니 코드의 모든 섹션이 대문자와 소문자 간의 사후 적 매핑을 포함하지는 않으며 두 세트의 사례도 있습니다.
"대소 문자를 구분하지 않음"은 의미가 없으며 오해의 소지가 있습니다.
이제는 내가 생각할 수있는 모든 것입니다. ASCII 세트에서, 당신이 Foo와 foo를 다르게하고 싶지 않다면, 나는 그 요점을 보지 못합니다.
얼마나 많은 사람들이 편향이 무엇을 의미하는지 알고 싶어하는지 궁금한가요? :-). 기본 집합 이론/조합론이없는 사람들은 위키피디아없이 어둠 속에서 빠져 나올 것입니까? – Bill
대소 문자를 구분하지 않는 것은 개발자가 SQL을 작성할 때 규칙을 따르지 않거나 VB와 같이 대소 문자를 구분하지 않는 개발 언어에서 온 경우에 발생합니다.
일반적으로 ID, ID 및 ID가 고유 필드 일 가능성이없는 데이터베이스를 다루는 것이 더 쉽습니다.
고문을 개인적으로 선호하는 것 이외에는 대소 문자를 구분하지 않는 것이 좋습니다.
내가 감당할 수 있었던 유일한 데이터베이스는 대평원이었다. 나는 그들의 스키마 명명의 모든 단일 케이스가 아프다는 것을 기억해야한다는 것을 알았다. 나는 최신 버전을 사용할 수있는 특권이 없었다.
변경되지 않은 경우 및 내 메모리가 작동하는 경우 설치 시간에 사용자가 대소 문자를 구분하는 특성이 결정되고 모든 데이터베이스에 적용됩니다. 그 설치의 모든 데이터베이스가 대소 문자를 구분한다는 것을 언급 한 Great Plains 데이터베이스를 실행 한 것은 SQL Server 설치와 관련이있었습니다.
SQL 식별자는 대소 문자를 구분해야합니다. 하나만 생각하면 은이고 하나는 MySQL이 왜 테이블 이름이 대소 문자를 구별하는지 알려주는 것입니다. 각 테이블은 디스크상의 파일이고 파일 시스템은 대소 문자를 구별하며 MySQL 개발자는 table_file = lc(table_name)을 잊어 버렸다. 이것은 MySQL 스키마를 대소 문자를 구별하지 않는 파일 시스템으로 옮길 때 재미있는 부분입니다.
대소 문자를 구분해서는 안되는 한 가지 큰 이유가 있습니다.
일부 스키마 작성자는 영리하게 될 것이며 this_table은 분명히 This_Table과 다른 것을 의미하며이 두 테이블 (또는 열)을 결정합니다. 스키마의 해당 시점에 "여기에 버그를 삽입하십시오."이라고 쓰십시오.
대소 문자를 구별하지 않으므로 SQL에서 스키마 작성자가 결정한 사항을 지키지 않고 테이블 및 열 대 명령을 강조하는 데 더 많은 표현을 할 수 있습니다.소문자 구분이 게으른 사용자를위한 것입니다 등 대부분의 비교 알고리즘, 대부분의 파일 시스템이기 때문에 거기
SELECT this, that FROM Table;
대부분의 언어는 대소 문자를 구분합니다. 유형을 쉽게 지정하는 경향이 있지만 동일한 이름의 여러 변형이 경우에 따라 다릅니다.
개인적으로, (MYTABLE을 MyTable, myTable에, MYTABLE, MYTABLE, MYTABLE, MYTABLE) 사이에, 나는 는 한 보편적 인 버전을보고 싶어하시기 바랍니다 것입니다.
저는 Sybase Advantage Database Server를 지원하며 DBF와 우리 고유의 ADT 형식을 허용하는 플랫 파일 형식을 사용합니다. 대소 문자를 구분하는 것이 문제가되는 경우는 Linux 버전의 서버를 사용할 때입니다. Linux는 대소 문자를 구별하는 운영 체제이므로 모든 호출을 소문자로 처리 할 수있는 옵션이 DB에 있습니다. 이를 위해서는 테이블 파일이 소문자 여야합니다.
필자는 대소 문자를 구분하기를 좋아하는데, 그 이유는 Perl (및 다른 대부분의 언어도 마찬가지)에서 프로그래밍하는 데 익숙하기 때문입니다. 나는 테이블 이름에 StudlyCaps를 사용하고 열에는 밑줄을 사용하여 모든 소문자를 사용하는 것을 좋아합니다.
물론 많은 데이터베이스에서 Postgres처럼 대문자 사용을 위해 이름을 인용 할 수 있습니다. 그것은 합리적인 접근법처럼 보인다.
저는 SQL Spec이 대소 문자를 구분할 필요가 있음을 확신합니다 (실제로는 무감각과 같습니다). PostgreSQL은 폴드가 낮아지고 ORACLE은 위쪽으로 폴드합니다.
그게 우리가 할 수있는 유일한 이유입니다. – nickd
다른 대답 : 테스트 시스템의 절반을 대소 문자를 구분하고 나머지 절반은 구분하지 않습니다. 이렇게하면 두 종류의 버그를 모두 잡을 수 있습니다. – Darron
우리는 DEV와 TEST에서 다른 서버 데이터 정렬을가집니다. 이렇게하면 실수로 서버 설정에 의존하는 날짜 형식 (예 : SProc) 및 만든 임시 테이블에 항상 COLLATE를 지정할 수 있습니다. – Kristen