코드 형식 SQL 쿼리

다른 줄에서 SQL 쿼리를 중단해야합니까? 예를 들어 작업중 인 프로젝트에서 1600 개의 열을 사용하는 쿼리가 있습니다! 1600 + 탭 문자 나는 이런 쿼리를 썼다 :

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

그러나 그들은 한 줄에 넣으라고 요구했으며 내 스타일은 잘못된 형식이라고 말했습니다. 왜 나쁜 습관입니까?

소스 제어상의 이유로 모든 where 절 또는 쉼표 뒤에 줄 바꿈이 있습니다. 위의 내용은

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(탭 및 정렬에는 표준이 없지만 일반적으로 쉼표가 사용됩니다)

여전히 성능 차이는 없습니다.

1600 열인 쿼리는 좋은 DBA의 진지한 검토가 필요한 것처럼 들립니다.

쿼리가 복잡한 경우 래핑합니다. 간단하다면 너무 길지 않으면 한 줄로 남겨두고 다시 줄 바꿈 할 것입니다.

조직이 코드 형식 규칙을 가지고 있지 않는 한, 관리 효율성과 그에 대한 이해를 통해 래핑 여부를 래핑 할 수 있습니다.

재 : 그것은 나쁜 코딩 연습입니다. 거의! 아주 좋은 연습입니다. 쿼리를 오래 사용해야하는 이유는 없으며 형식을 다시 지정해야하는 여러 가지 이유가 있습니다. 앞서 말했듯이, 숙련 된 DBA는 아마도 그 일을해야 할 것입니다.

염두에 둔 단선 쿼리의 유일한 장점은 이러한 쿼리를보다 쉽게 ​​파악할 수 있다는 것입니다. 그러나 그 외에는 난처하지 않습니다. 개인적으로, 더 읽기 쉬운 분할 쿼리를 선호합니다.

여러 줄 주석은 많은 양의 SQL을 처리 할 때 매우 중요합니다. 또한 프로그래밍 언어에 인용 부호가 있으면 훨씬 좋습니다 (많은 편집자가 SQL 구문을 강조 표시 할 수 있음).

예:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

수십 줄 (또는 수백 개)의 쿼리로 작업 할 때 들여 쓰기와 공백은 텍스트를 실행 가능하게 만듭니다.

이것은 프로그래밍 언어로 큰 쿼리를 정의하는 것과 관련이있는 것으로 보입니다. 쿼리 리터럴에 쿼리를 넣고 연결하는 것을 볼 수 있습니다.

컴파일 된 언어 인 경우 전혀 차이가 없어야합니다. 컴파일러가 수행하는 첫 번째 최적화 중 하나는 문자열 리터럴을 자동으로 연결하는 것이므로 결국 큰 문자열로 끝납니다.

구문에 대해서는 실제로 쿼리를 코드 외부로 이동시키는 것을 고려해야합니다. 별도의 .sql 리소스 파일에 저장하고 소프트웨어가 해당 파일을 읽도록하십시오. 변수가 동적으로 작성된 쿼리가 아닌 경우 변수에 대해 준비된 명령문을 사용하십시오 (예 : 특정 매개 변수에 따라 where 절 등이 추가됨). 동적으로 작성된 경우 필요에 따라 언제 어디서나 추가 매개 변수를 삽입하여 자신 만의 대체 변수를 추가 할 수 있습니다.

1600 열의 경우 그에 대한보기를 작성하는 것이 좋습니다.

SELECT column1, column2, .... column1600 from X where Y

당신은 얻을 것이다

뷰 *에서 선택 * 어디에서

자신의 코드에서 훨씬 더 간결합니다.

복잡한 쿼리 문제를 해결하기 위해 @glasnt에서 제공 한 형식을 사용하지만 대개 한 줄에 쿼리가 있습니다.

이것은 귀하의 질문에 대답하지 않을 수도 있지만, 귀하의 검색어를 더 작은 검색어로 나누는 것이 좋습니다. 분명히 이것은 쿼리에 따라 다르지만 더 많은 절과 조인을 쿼리에 추가하면 SQL 엔진이 쿼리를 최적화 할 수있는 수준이 줄어 듭니다.

데이터베이스 공급 업체에는 MySQL EXPLAIN (또는 MSSQL의 SHOWPLAN_ALL 설정)과 같은 도구가 있어야합니다.이 도구를 사용하면 데이터베이스가 임시 테이블을 만들거나 그와 같은 일부를 추가 할 때마다 쿼리를 최적화하기 위해 데이터베이스에서 수행중인 작업을 보여줄 수 있습니다. 여러 명의 동시 사용자에 대해 이야기 할 때 엄청난 지연이 발생합니다.

사소한 논리처럼 보일 수있는 것을 SQL에서 코드로 옮기면 성능이 크게 향상 될 수 있습니다. SQL은 간단한 작업에서 훌륭합니다.

이와 관련하여 명백한 이점은 쿼리가 훨씬 덜 복잡하고 읽기 쉬워서 관리하기 쉽고 (1600 개가 아닌 열) 더 빠르다는 것입니다. 확실하게 만능 승리.

도움이 되었기를 바랍니다 :)