[sql] SQL 키워드에 대문자를 사용해야 할 이유가 있습니까? [닫은]

기본값은 대문자 인 것 같지만 키워드에 대문자를 사용해야하는 이유가 있습니까? 새로운 저장 프로 시저와 같이 무언가를 만들려고 할 때마다 SQL Server가 제공하는 것과 일치하려고했기 때문에 대문자를 사용하기 시작했습니다. 그러나 나는 항상 Shift버튼 을 누르고 있어야하는 내 아기 (5 번째) 손가락에 끔찍한 느낌이 들었 으므로 대문자 사용을 중단했습니다. 대문자로 돌아 가야하는 이유는 무엇입니까?

편집 : 답변들 주셔서 감사합니다. 나는 COBOL 이 왕이었던 시절에 아직 프로그래밍하지 않았 으므로 이것을 알지 못했습니다. 나는 지금부터 소문자를 붙일 것이다.



답변

그것은 스타일의 문제 일 것입니다. 아마도 에디터가 코드 채색을하지 않은 시절에 시작되었을 것입니다.

나는 모든 대문자를 선호했지만 지금은 모두 낮은쪽으로 기울고 있습니다.


답변

개인적으로, 나는 저의 SQL 소리를 좋아하지 않습니다. 그것은 기본 또는 코볼의 저를 연상시킵니다.

따라서 데이터베이스 개체 이름이 MixedCase 인 T-SQL 소문자를 선호합니다.

읽는 것이 훨씬 쉽고 리터럴과 주석이 두드러집니다.


답변

SQL이 오래되었습니다. 대문자가 외칩니다. 그것은 상쾌하고 끔찍하게 보입니다.

논란의 여지가 있지만, 대문자 키워드가 좋은 규칙 인 SQL 언어에 특별한 이유를 다루지는 않습니다 .

많은 새로운 언어와 달리 SQL에는 많은 키워드가 있으며 구문을 정신적으로 구문 분석하기 위해 키워드와 식별자구별 하는 독자의 능력에 의존 합니다.

그렇다면 귀하의 질문에 대한 직접적인 대답은“ 대부분의 현대 언어에서 그렇지 않은 경우 대문자 코드에서 SQL 코드 독자가 왜 그렇게 많은 이점을 얻 습니까?”에 대한 답입니다.

  • 키워드를 머리 속에 두는 것은 많은 현대 언어에서는 합리적 이지만 SQL 에서는 비합리적입니다 . 너무 많은 키워드와 너무 많은 변형이 있습니다.

  • 문장 부호에 의존하는 것은 대부분의 현대 언어에서는 합리적 이지만 SQL 에서는 비합리적입니다 . 구문을 나타 내기 위해 키워드의 정확한 순서에 따라 너무 적습니다.

  • 키워드를 구별하기 위해 자동 하이 라이터 에 의존하는 것은 일반적인 경우에 현대 언어에서는 합리적이지만 SQL에 대해 하이 라이터가 달성 할 수있는 현실은 무시합니다 . 대부분은 모든 SQL 변형의 키워드를 모두 다루지는 않으며, 어쨌든 형광펜이 도움이되지 않는 상황에서 SQL을 자주 읽고 정기적으로 읽습니다.

SQL과 관련하여 SQL 코드 독자가 키워드의 대문자를 표준화하고 식별자에 대해 대문자가 아닌 (즉, 소문자 또는 혼합) 대소 문자 만 사용 하는 것이 가장 좋습니다 .

강조 표시가 도움이 될 수 있습니다. 그러나 형광펜이 SQL을 가지고 있다는 것을 알고있는 경우에만; 에디터 / 포맷터가 SQL을 다루는 것을 합리적으로 알 수없는 상황에서 종종 SQL을 사용합니다. 예를 들어 인라인 쿼리, 프로그래머 문서 및 다른 언어 코드 내의 텍스트 문자열이 있습니다. 파이썬이나 C ++와 같은 언어의 경우가 아닌 다른 곳에서도 마찬가지입니다. 그렇습니다. 그들의 코드는 때때로 그 장소에 나타나지만, SQL 코드와 같은 방식으로 일상적으로 수행되는 것은 아닙니다.

또한 독자는 일반적으로 특정 SQL 구현에서 사용하는 키워드의 하위 집합 만 알고있는 형광펜을 사용합니다. SQL 변형을 자세히 알고있는 키워드를 제외하고 일반적이지 않은 많은 키워드는 강조 표시되지 않습니다. 따라서 독자는 형광펜을 사용하더라도 약간 복잡한 SQL 문에서 키워드를 구별하는 더 직접적인 방법이 여전히 필요합니다.

따라서 독자는 자주 (필자가 언제인지 미리 알 수 없음) SQL 문 자체의 내용에서 도움을 받아야합니다. 따라서 SQL 컨텐츠 자체 는 독자의 키워드구별 해야하며 대문자 키워드를 사용하는 것이 일반적이고 유용한 방법입니다.


답변

Gordon Bell의 예는 정확히 맞지 않습니다. 일반적으로 전체 검색어가 아닌 키워드 만 강조 표시됩니다. 그의 두 번째 예는 다음과 같습니다.

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

키워드가 더 눈에 띄기 때문에 이것을 훨씬 쉽게 읽을 수 있습니다. 구문 강조 표시를 사용해도 대문자가 아닌 예제를 읽기가 더 어렵다는 것을 알았습니다.

우리 회사에서는 SQL 형식화를 조금 더 진행했습니다.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1


답변

대부분의 사람들이 관련 인코딩 (ASCII)이 아직 발명되지 않았기 때문에 상위 사례 문자 이외의 다른 방식으로 인코딩 할 수있는 시간이 없었습니다. 6 개의 비트 만 사용 가능합니다 . SQL이 최근에 더 많이 나왔지만 더 낮은 사례는 프로그래밍에 대한 일반적인 관행이 아닙니다.

참고 어떤 사람들은 주장 데이터베이스가 긴박감을 얻고 빠르게 쿼리를 실행됩니다.


답변

우리가 읽은 본문에서 글자의 10 % 미만이 대문자입니다. 따라서 우리의 두뇌는 대문자보다 소문자를 인식하는 데 더 열중합니다. 연구에 따르면 대문자 텍스트를 읽는 데 시간이 오래 걸립니다. 다음은 한 가지 예입니다.

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

위의 예는 한두 단어 만 말할 때도 차이가 있음을 강조합니다.


답변

SQL은 구식 언어 ( 1974 ) 이기 때문에 대부분의 키보드에는 소문자가 없었습니다! 언어 문서에는 단순히 당시의 기술이 반영되어 있습니다.

연구에 따르면 모든 CAPS를 읽기가 더 어렵다는 사실이 입증되었으므로 미국 연방 고속도로 관리국은 다음과 같이 통일 교통 제어 장치에 대한 설명서에서 대소 문자를 혼합하여 사용해야합니다.

기존 도로 안내 표지의 장소, 거리 및 고속도로 이름에 대한 글자는 소문자와 초기 대문자의 조합이어야합니다.

뉴욕 포스트는 또한 다음을 발표했습니다.

연구에 따르면 모든 대문자 표시를 읽는 것이 더 어렵다는 것이 밝혀졌으며 도로에서 멀리 떨어진 곳에서 밀리 초를 소비하면 특히 노인 운전자의 사고 가능성이 높아지는 것으로 나타났습니다.

대문자를 사용해야 할 합당한 이유가없고하지 않는 좋은 이유가 있습니다.

개인적으로 SQL 키워드에 대문자를 사용하는 것을 싫어합니다. 나는이 시대에 읽고 터무니 기가 더 어렵다는 것을 알게되었습니다.

SQL 언어는 대소 문자를 구분하지 않는 것으로 정의됩니다. 그 Shift 키에서 손가락을 떼십시오!