코드 쉼표로보기 - 어느것이 효율적입니까? 320GB의 SQL 코드 조사

 SQL코드에서 쉽표를 앞에 붙이냐 뒤에 붙이냐에 대한 질문을 데이터적으로 분석한 해외 포스팅이 있어서 소개합니다. 개인적으로는 무엇이 중요하나 싶지만 접근 방법과 다루는 내용이 흥미로워 번역해서 올립니다. 출처는 포스팅 끝에 있습니다.

 320 기가의 오픈 소스 SQL 코드를 분석하여 후행 쉼표 또는 선행 쉼표를 사용해야하는지 확인해 봅시다. 인기만으로는 충분하지 않습니다. 어떤 스타일이 성공으로 이어질 수 있을까요?

 BigQuery의 SQL을 표준 SQL : 2011 로 전환하는 것은 좋지 만 다음을 제외하고는 훌륭했습니다. 더 이상 쉼표를 사용하지 않아도됩니다. 라인을 추가, 제거 및 주석을 달 때 실제로 실용적입니다 (Go에서는 이것이 적용 됩니다). 생산성을 높이기 위해 필자는 논란의 여지가있는 스타일로 전환해야했습니다. 이제 열거 형 행을 쉼표로 엽니다.

 쉼표로 시작하는 것은 대중적인 스타일이 아닙니다. 그러나 그것이 생산적인 일수 있습니다. 이걸 증명하기 위해 80,000 개의 GitHub 저장소에서 320GB의 SQL 코드를 분석합니다.

 많은 프로그래밍 언어 (C, Python, JavaScript, Go , ...)를 사용하면 목록의 마지막 요소 다음에 쉼표 를 남길 수 있습니다 . 하지만 다른 사람들은 SQL (또는 JSON 형식)을 좋아하지 않을 것입니다. 이것은 관행을지지하는 소수파의 의견입니다. 효율적인 코드 작성 및 변경 관리라는 이름으로 쉼표로 시작하는 새 줄을 시작하십시오 .

다음과 같이 SQL 코드를 선호 하시겠습니까?

# 후행 쉼표 
SELECT 이름, 
  회사, 
  급여, 
  주, 
  도시 
FROM`employees` 
WHERE state = 'CA'

또는 이런 코드 :

# 선행 쉼표 
SELECT 이름 
  , 회사 
  , 급여 
  , 주 
  , 도시 
FROM`employees` 
WHERE state = 'CA'

다행히도 우리는 테라 바이트의 오픈 소스 코드에 액세스하여 BigQuery 분석 할 준비가되었습니다 . 사용 가능한 모든 추출 코드가있는 거대한 테이블이 있습니다. 추가 분석을 수행하기 전에 첫 번째 단계에서 관심있는 코드 만 추출해야합니다.

".sql"파일의 모든 코드를 새 테이블로 가져 오려면 다음을 수행하십시오.

#standardSQL 
SELECT a.id ID, 크기, 내용, 바이너리, 복사본, 
  sample_repo_name, sample_path 
FROM ( 
  SELECT ID 
    , ANY_VALUE (경로) sample_path 
    , ANY_VALUE (repo_name) sample_repo_name FROM`bigquery 
  -public-data.github_repos.files` 
  WHERE PATH LIKE '% .sql'GROUP 
  BY 1 
) 
JOIN`bigquery-public-data.github_repos.contents` b 
ON a.id = b.id

이것은 GitHub에서 총 2 백만 개의 SQL 파일을 나타내는 테이블을 제공합니다 - 320 GB 이상의 코드!

BigQuery에서이 테이블 의 향상된 공개 사본을 남겨 두었 으므로 곧장 다음 단계로 넘어갈 수 있습니다.

결과:

1.쉼표로 끝나는 SQL 행은 5 천만 개에 불과하지만 140 만 개는 하나에서 시작합니다.

2.쉼표가 329,308 개의 고유 한 SQL 파일이 있으며, 단 18,312 개의 SQL 파일에는 주요한 SQL 파일이 있습니다.

3.쉼표가 포함 된 SQL 파일에는 최소한 72,506 개의 리포지토리가 있지만, 리딩 쉼표에는 3,360 개의 리포지토리 만 존재합니다.

4.요약 : 선행 쉼표는 인기 경쟁을 상실합니다 . 방법과 프로젝트를 사용하는 파일이 적습니다.

부가 설명 : 시작과 끝에 쉼표가있는 1,029 개의 파일에는 5,647 개의 SQL 행이 있습니다. 최소한 360 개의 저장소가 이러한 괴물을 허용합니다.

두 번째 접근 방식 : 성공 메트릭 통합

인기있는 길을 잃는 것은 도로의 끝이 아닙니다. 우리는 스스로에게 묻습니다 : " 어느 프로젝트가 더 성공적 입니까? "

GitHub에서 성공적인 코드를 어떻게 정의 할 수 있습니까? 별의 수? 작년에 별이 있었나요? 올해 별의 수는? 활성 사용자 수? 일반적인 활동 수준?

규칙:

각 저장소는 라인 수나 파일 수에 관계없이 한 표를 얻습니다.

많은 저장소에있는 파일은 대부분의 별이있는 파일에 할당됩니다.

리포 지 토리는 4 개의 그룹 중 하나에 할당됩니다 : 선행 또는 후행 쉼표, 행 끝의 쉼표 또는 두 가지 스타일의 혼합.

다음은 결과입니다.

결과 :

 

 적은 수의 프로젝트 만 선행 쉼표를 사용하고 더 많은 스타일을 혼합 할 수 있으며 대다수는 쉼표 만 사용할 수 있습니다. 대부분의 프로젝트 (최소 69,665 repos)는 SQL 행의 끝에 쉼표 만 표시합니다. repos는 선행 쉼표 만 표시하고 2,847은 두 가지 스타일의 혼합을 사용합니다.

 스타일을 혼합하여 사용할 수있는 프로젝트가 가장 효과적입니다. 평균 혼합 스타일 프로젝트에서 29.37 개의 별, 11.73 명이 참여했으며 올해 동안 150 개 이상의 이벤트가있었습니다. 비교해 보면 프로젝트 만 추적하는 SQL 쉼표는 올해 13.06 개의 별, 5.49 명의 사람들, 50 개 미만의 이벤트를 포함합니다 (지금까지).

 

선행 쉼표를 적용하는 프로젝트 는 혼합 된 프로젝트만큼 큰 성공 을 보이지는 않지만 여전히 유일한 후행 프로젝트 보다 나은 것으로 보입니다.

추세는 수시로 안정적입니다.  - 진행중인 2017 년 동안 별의 수, 2016 년의 별, 별, 사람 및 활동을 비교합니다.

관련 인용문

후행 쉼표를 허용 하는 PostgreSQL 제안서 에서 :

 내 경험상, 목록의 첫 번째 항목을 엉망으로 만드는 경우는 거의 없으며 대부분 문제를 해결합니다. 선행 쉼표가 누락 된 경우에도 쉼표가 누락 된 것보다 더 쉽게 발견됩니다.

그리고 reddit 에서 후행 쉼표를 시행합니다 .

"JSON은 목록의 마지막 항목에 쉼표가없는 것을 싫어합니다."

"또한 재주문 작업을 멋지게 처리하지만 CSV를 다른 언어로 미워하는 의도하지 않은 결과를 초래합니다."

"Go에서 처음 시작했을 때, 나는 문법과 워크 플로우에 대해 거의 모든 입장을 싫어했습니다. 이런 작은 물건들은 나를 미치게 만들었고, 나를 위로했고, 끝까지 나를 좌절 시켰습니다. 하지만 잠시 후, 이런 것들은 제가 가고 싶은 것에 변합니다. "

"나는이 작은 특징을 즐긴다. 오늘 옥타브 (Octave)를 사용하면 아이템을 추가하고 삭제할 때 다른 언어로 시간을 낭비하게됩니다. 

이처럼 많은 작은 것들이 있으므로 "Go"를 사용하는 것이 즐겁습니다. "

"이 작은 후행 쉼표 기능은 내가 Go가 많은 경험을 가진 사람들에 의해 디자인되었다는 것을 깨닫게 한 첫 번째 것입니다. 꼬리표없이 쉼표를 사용하면 내 손가락에 통증이 생기지 만 Go에서는 몇 줄을 선택할 수 있습니다. 명령 : sort (저는 정력적 인 사람입니다)과 voilà! "

출처

https://hackernoon.com/winning-arguments-with-data-leading-with-commas-in-sql-672b3b81eac9