직접 작성된 코드에서 SQL Server의 대괄호 표기법을 사용하는 것이 합리적입니까?

코드 생성기는 []거의 모든 것에 대해 새로운 Microsoft 대괄호 표기법 ( )을 사용하여 출력을 생성 할 때 더 단순한 경향이 있습니다 .

처음 보았을 때 다소 금지 된 인용 표기법에 대한 환생을 좋아합니다.

내가 아는 한 이것은 Microsoft의 독점적 인 확장입니다 (Oracle은 그것을 지원하지 않음을 의미합니다).

SQL Server를 보면 다음과 같은 테이블을 정의해도 차이가 없습니다.

CREATE TABLE [dbo].[Table_2] ([col1] [int], [col2] [int]);

또는

CREATE TABLE dbo.Table_2 (col1 int, col2 int);

그것은 개인 또는 회사 스타일의 문제입니다. 일관성을 유지하십시오.

이제 데이터베이스를 Oracle로 마이그레이션하려는 경우 대괄호는 옵션이 아닙니다.

오래된 인용 식별자를 사용할 수 있지만 대소 문자를 구분하므로 많은 문제가 발생합니다.

생성 된 코드에서 모든 대괄호를 제거하고 이름에 공백, 기타 특수 문자 및 예약 키워드를 사용하지 말고 대부분의 DBMS가 이해하는 방식으로 코드를 작성하는 것이 좋습니다.

표준 SQL은 따옴표 "붙은 식별자에 큰 따옴표 를 사용합니다 . SQL Server는 QUOTED_IDENTIFIER옵션 ( ANSI_QUOTESmySQL에서)을 사용하여이를 지원합니다 . 표준 SQL은 일반적으로 이식성을 향상 시키며이 경우 Oracle로 이식됩니다. 마찬가지로 SQL 키워드를 대문자 (중간 SQL-92 요구 사항)로 변경하고 (입력 레벨 SQL-92 요구 사항)으로 확장 int했습니다 INTEGER.

맛에 상관없이 인용 된 식별자를 사용하는 것은 피해야합니다 (IMO).

이 문제는 주관적인 문제이지만 불필요한 괄호는 내 애완 동물 친구 목록의 상단에 있습니다. 맞춤법 오류 "! ="보다 약간 더 성가 시지만 열 목록에서 선행하는 쉼표만큼 나쁘지는 않습니다.

객관적으로 말하면 대괄호의 목적을 고려하십시오. 그렇지 않으면 합법적이지 않은 객체 이름을 허용합니다. 이러한 목적을 감안할 때 대괄호는 최악 의 코드 냄새 이며 게으름의 징후입니다.

• 테이블 또는 열 이름이 다음과 같은 경우 대괄호가 필요합니다.

  • 공백을 포함하십시오 : SELECT [column name] FROM table;
  • 괄호 포함 : SELECT [wt[f]또는SELECT [wt]]f]
  • or 와 같은 영숫자 가 아닌 기호를 포함합니다 (예, 해당 기호를 포함 할 수 있습니다).^!
  • 있는 예약 된 키워드 등이 KEY, STATE, RULE, ...

  스키마를 제어 할 수있는 경우에는 이와 같은 이름을 사용하지 마십시오. 그러나 경우에 따라 최상의 이름은 예약 된 이름이므로 ( KEY일반 키-값 테이블의 키 열과 같이 ) 사용 빈도를 결정하는 것은 사용자의 몫입니다 (따라서 어디서나 인용해야 함).

  또한 SSMS와 VS DESCRIPTION가 SQL Server에서 예약하지 않았지만 이러한 도구에 특별한 키워드를 제공하는 파란색 강조 표시를 억제하기 위해 대괄호를 사용 합니다.

• 동적으로 SQL을 생성 할 때 대괄호를 사용하십시오. 그렇게하는 가장 쉬운 방법 QUOTENAME()은 동적으로 참조하는 객체를 호출 하는 것입니다 (예 :) SELECT QUOTENAME(name) FROM sys.databases;. sp_MSforeachdb예를 들어이 작업을 수행하지 않습니다 .

코드를 생성하는 코드를 작성할 때 데이터베이스 개체 이름을 대괄호로 묶습니다. 직접 코드를 작성할 때 대괄호를 포함하지 않으며 코드의 가독성이 떨어집니다. 또한 공백이있는 데이터베이스 오브젝트 이름을 금지합니다. SQL Server를 사용하면 개체 이름에 공백을 사용할 수 있지만 이것이 좋은 의미는 아닙니다.

휴대용 DDL을 사용하려고 시도조차하지 않을 것입니다. 필요한 경우 SQL Server의 시스템 뷰에서 Oracle 테이블 정의를 생성하면 더 나을 것입니다.

휴대용 DML을 작성하는 것이 타당하지 않다고 생각합니다. PL / SQL은 T-SQL과 완전히 다릅니다. 이식성을 위해 저장 프로 시저 API를 통해 데이터베이스를 노출하는 것이 더 쉽습니다. 이러한 절차의 서명은 두 플랫폼에서 동일해야하지만 구현시 독점 기능을 사용할 수 있습니다. 전반적으로 ANSI 표준 SQL 만 사용하는 것보다 훨씬 쉽습니다.

이 결론은 Oracle과 SQL Server 모두에서 작업하면서 휴대용 시스템을 개발 한 몇 년의 경험을 바탕으로합니다.