모든 SQL 문은 DBA에 의해 검토되어야합니다.

스키마 변경뿐만 아니라 모든 것을 의미합니다. 기본 키의 간단한 SELECT조차도 모든 개발자가 코드에서 추출하여 EXPLAIN 출력, 세부 정보로 제출 한 모든 명령문에 대한 DBA 검토없이 다른 개발자 (상황에 따라)에서 코드를 검토했지만 프로덕션에 들어갈 수 없습니다. 얼마나 자주 호출되는지 등

그러한 환경에 있었다면, 순이익이나 개발에 끌리는 것으로 나타 났습니까? 수년 동안 관계형 데이터베이스를 사용해온 사람으로서 "개발자가 데이터베이스를 사용하도록 신뢰할 수 없음"이라는 태도가 부적절하다는 것을 알았으며이 상황이 얼마나 흔한 지 궁금합니다. 가치있는 것은 웹 개발만을위한 것이지 중요한 것은 아닙니다.

저의 이전 직업 중 하나에서 (다른 프로그래머 3 명과 함께) 약 40 명 이상의 프로그래머를 위해 프로덕션에 들어가기 전에 작성 또는 업데이트 된 모든 저장 프로 시저를 검토해야했습니다. 리뷰어로서 그것은 내 시간에 정말로 끌 렸지만 전반적으로 여전히 필요했습니다. 많은 개발자가 한 번에 실수를 저지를 것이기 때문입니다. 우리는 실제로 나쁜 (효율적인 현명한) SQL 문을 쓴 해상 프로그래머가 있었기 때문에 배우기를 거부했습니다 (그 팀은 결국 종료되었습니다).

전체적으로 우리는 다음을 찾았습니다.

• 인덱스 사용법-쿼리에서 전체 테이블 스캔을 수행 했습니까?
• 유지 관리 성-무언가가 하드 코딩되어 있기 때문에 몇 주 안에 쿼리를 변경해야합니까? 쿼리를 읽을 수 있습니까?
• 전반적인 효율성-내부 결합을 기존 것으로 대체 할 수 있습니까? With 블록 도움말을 추가 하시겠습니까?
• 잠금 문제-쿼리가 데이터베이스를 잠그고 업데이트가 발생하지 않습니까? 이것은 내가 생각하는 것보다 더 많이 일어났다.

대부분의 쿼리에 문제가 없었을 때가 많았으며이를 추진했습니다. 그러나 각 검토에는 쿼리에 따라 10 분에서 2 시간이 걸렸습니다. 일부는 다른 응용 프로그램에서 일부 보고서에 문제가 발생했기 때문에 2 AM 전화가 두려운 것을 막았 기 때문에 리뷰를하는 아이디어를 좋아했습니다. 그러나 동시에 나는 우리 모두 어른이며 쿼리를 작성하는 사람이 모든 것을 스스로해야하기 때문에 약간 과잉이라고 생각했습니다.

복잡한 쿼리는 표준 코드 검토의 일부 여야한다고 생각하지만 DBA를 거칠 필요는 없습니다. 간단한 insert / update / delete 문을 검토 할 필요도 없습니다. 또한 쿼리 작성자로서 쿼리가 너무 복잡해지면 DBA에 검토를 요청할시기를 알아야합니다.

업데이트 첫 번째 작업에서 모든 쿼리는 DBA에 의해 작성되었으며 이는 개발에있어 주요한 시간 킬러였습니다. 원하는 모든 열, 열이 위치한 테이블 및 마지막으로 검색 기준을 제출해야했습니다. 기본 삽입 / 업데이트 / 삭제 명령문조차도 DBA를 통과해야했습니다. 결국 나는 내가 원하는 SQL을 작성하고, 그것을 살펴보고 필요한 변경을 한 다음 저장 프로 시저를 감싸도록 지점에 도달했지만 몇 년이 걸렸다. 이 회사는 최근에 많은 대학 졸업생을 고용했으며 이것이 새로운 직원이 성능을 저하시키는 쿼리를 작성하지 않도록하는 방식이었습니다.

그것은 환경, 산업 및 회사에 전적으로 달려 있습니다.

몇 가지 예 :

• NASA에서는 여러 수준의 점검 및 검토가 표준입니다. 가장 잘 알려진 "두 배로 확인해야한다"는 탐사선이 화성에 보내졌고 미국은 피트 단위로 계산했지만 유럽인은 미터 단위 로 측정했을 때였습니다 . 프로브가 유실되었습니다.

• DBA가없는 스타트 업 (일반적으로 요즘)에는 DBA 검토가없고 프로그래머 검토가 없을 수도 있습니다 (예 : 회사에 다른 프로그래머가없는 경우).

• 제품이 수억 행의 데이터웨어 하우스 인 회사에서 쿼리가 효율적이고 정확한지 확인하는 것은 점검해야 할 비즈니스 핵심 핵심 문제 일 수 있습니다.

데이터베이스 상호 작용이 적고 주로 정적 웹 사이트 인 주 제품을 사용하는 회사는 데이터베이스와 그 효율성이 덜 중요하다고 생각할 수 있습니다. 회사는 가장 중요한 것으로 간주되는 정적 페이지에서 "예산"을 검토하기로 선택했을 수 있습니다.

나는 그런 환경에서 일한 적이 없다. 나는 그것을 싫어할 것이라고 확신한다. 이것에 대한 몇 가지 메트릭을 추적하기 시작하는 생각이 떠 오릅니다 ...

• 개발자는 코드에서 SQL을 가져와 DBA에 제출하기 위해 준비하는 데 얼마나 많은 시간을 소비합니까?
• DBA가 SQL을 검토하는 데 얼마나 걸립니까?
• DBA는 얼마나 자주 변경을 요청합니까? 쿼리
  유형별로 분류 되었습니까?

이것을 잠시 동안 추적하면 드래그의 효과와 효과의 정도를 알 수 있습니다.

대부분의 개발자는 데이터베이스와 관련하여 무지합니다. 그들은 심지어 그들의 무지를 알지 못합니다. 예전에는 무지한 개발자였습니다.

개발자는 최적화가 나쁜 세상에 살고 있습니다. 디스크에 대한 작업을 수행 할 때는 해당 사고 방식이 작동하지 않습니다. 해당 마인드 세트는 필요한 것보다 8 배 더 큰 데이터 유형을 선택할 때 작동하지 않으므로 인덱스가 필요한 것보다 8 배 더 커지므로 더 이상 메모리에 맞지 않을 수 있습니다. 이 사고 방식은 테이블의 모든 열을 중복 업데이트하는 일반 API에 대해 프로그래밍 할 때 작동하지 않습니다 (Java Bean 없음).

그들은 전체 테이블 스캔이 무엇인지 모릅니다. 커서를 여는 대신 단일 세트 작업으로 데이터를 처리하는 방법을 모릅니다. 커서보다 데이터를 쿼리 한 다음 단일 간단한 일반 제인 업데이트로 충분할 때 데이터베이스에서 행 단위로 데이터를 처리합니다. 위험한 성능을 제공합니다.

그들은 큰 테이블에 대한보고의 심각한 영향을 모릅니다. 보고서가 필요할 경우 스타 스키마와 데이터 피드를 만들어야합니다. 평범한 개발자는 exisitng 테이블을 쿼리하고 쿼리 실행에 3 시간이 걸리는 이유를 궁금해합니다 (실제 수치 임).

일반 개발자가 알고있는 지식은 사용자가 단순히 레코드를 편집하는 "평균"CRUD 앱에 충분합니다. 루비 온 크랙 버블에서 빠져 나와 현실 세계로 빠져 나간 후에는 충분하지 않습니다.

데이터베이스의 크기와 여러 응용 프로그램간에 공유되는지에 따라 다릅니다. 종종 DBA 팀은 어떤 쿼리가 실행 될지 알고 싶어서 적절한 인덱스가 제자리에 있는지 확인하거나 테이블을 파티셔닝해야하는지 알 수 있도록합니다. 또한 쿼리 실행 계획을 읽고 성능을 향상시키기 위해 힌트를 지정할 수있는 장소를 찾는 데있어 일반 개발자보다 약간 더 나은 경향이 있습니다. 또한 다음 릴리스에서 영향이 큰 일부 쿼리가 제공 될 예정이므로 최적화 프로그램에 대한 다양한 통계를 수집 할 수도 있습니다.

나는 그런 환경에서 일하지 않았으며, 그렇게하지 않았습니다.

팀워크와 적대적인 관료주의에는 차이가 있습니다. 개발자로서 어려운 쿼리에 대한 DBA 입력을 원합니다. 그러나 언제 도움을 요청해야하는지 알고 있습니다.

간단한 SELECT쿼리를 할 수있는 능력 이 없다면 해고 당해야합니다.

나는 이것이 두 곳의 다른 곳에서 이루어 졌다는 것을 보았다. 이론적으로는 훌륭하지만 효과적이지 않습니다. 이유는 다음과 같습니다. 첫째, DBA 팀 (또는 다른 사람들)이 있다면, 나는 그룹의 가장 유능하거나 가장 좋아하지 않는 사람이 검토 작업의 강도를 얻는다는 것을 일반적으로 발견했습니다. 왜 그래? 다른 누구도하고 싶지 않기 때문에 다른 사람들은 아마도 더 시급한 다른 일을 하느라 바쁘기 때문입니다. DBA가 앉아있는 것을 본 적이 있습니다. "모든 것이 완벽하게 실행되고 있습니다. 그냥 앉아서 인터넷을 서핑 할 수 있습니다. 할 일이 있었으면 좋겠습니다." 나도, 적어도 좋은 것은 아닙니다. 그들은 다른 사람들보다 바쁘거나 바쁩니다. 이것은 가장 능력이 적은 사람이 검토를하고있을 가능성이 높으며, 이것은 당신이 원하지 않는 사람이라는 것을 의미합니다. 검토하려는 코드는 사람들이 일종의 흑 마법으로보고 실제로 전달하는 정말 어려운 코드입니다. 주니어 DBA 또는 평범한 나쁜 것들은 실제로 어려운 쿼리의 작동 방식의 미묘한 부분을 포착 할 수 없습니다. "아무도 기본 키를 사용하여 테이블에서 단일 행을 선택하는 것을 생각하지 않았습니다! 감사합니다. DBA 덕분에 생명의 은인입니다." 따라서이 시나리오에서 실제로하는 일은 거의 가치가없는 많은 작업을 만드는 것입니다. 기본 키를 사용하여 테이블에서 단일 행을 선택하는 것을 생각하지 마십시오! DBA에게 감사합니다. 여러분은 생명의 은인입니다. "따라서이 시나리오에서 실제로하는 일은 거의 가치가없는 많은 작업을 만드는 것입니다. 기본 키를 사용하여 테이블에서 단일 행을 선택하는 것을 생각하지 마십시오! DBA에게 감사합니다. 여러분은 생명의 은인입니다. "따라서이 시나리오에서 실제로하는 일은 거의 가치가없는 많은 작업을 만드는 것입니다.

둘째, DB 그룹에 대한 더 많은 작업입니다. 그들이 다른 것을 보더라도 일어날 수있는 일은 그들이 그것을 빨리보고 무언가가 놓칠 것입니다. 사람들이 바쁘기 때문에 코드를 검토하는 데 시간이 많이 걸립니다. 사실 그들은 다른 사람들이 게으르고 밖으로 나가는 데 대한 변명이기 때문에 그들이 이것으로 임무를 수행하는 것은 불공평합니다. 프로덕션 환경에 문제가 생겼으며 개발자는 "DBA가 잘 검토했다"고 신속하게 지적합니다. 이제는 항상 사실이지만, 시간의 일부이며 종종 코드를 실제로 검토 해야하는 사람들의 경우도 마찬가지입니다. 그래서 당신은 추가 작업으로 DBA를 묻었 고 그 사람이 다른 사람의 실수에 대해 책임을 지도록 강요했습니다.

실제로 문제를 해결하는 유일한 방법은 SQL 코드 작성 방법을 알고있는 사람들이 작성하도록하는 것입니다. 그들은 때때로 DBA로부터 입력을 받아야 하는가? 물론 그들은 그래야만합니다.하지만 처음부터 제대로 할 시간이 없다면 언제 고칠 시간을 찾을 것입니까?

나는 그런 종류의 환경에서 일했습니다. 모든 시스템 변경 사항은 해당 피어에 의해 피어 검토되었습니다. 나에게 그것은 단지 미리 계획하고 며칠 전에 변경 사항을 제출해야 함을 의미했습니다. SQL은 궁극적으로 SQL을 프로덕션으로 릴리스하는 DBA에게 갔다.

내 SQL은 일반적으로 괜찮으며 몇 가지 바보 같은 오류가 발생했습니다. 처음에는 지나치게 관료적 인 느낌이 들지만 나는 금융 분야에서 일합니다. 몇 개월 전에 여기에서 주요 은행이 정기 업그레이드를 엉망으로 만들고 수백만 명 (최소 수십만 명)의 사람들이 이룰 수없는 모든 거래를 엉망으로했을 때 무슨 일이 있었는지 (영국에 있다면) 그들의 돈으로.

나는 더 나아가고 싶었다. 주변 코드를 확인하고 변수가 쿼리에 어떻게 전달되는지 확인했습니다. 기본 지식이 부족하기 때문에 개발자가 애플리케이션을 sql injection 공격에 노출시키는 방법을 종종 볼 수 있습니다 ( "이것은 해킹 될 수 없습니다"라는 잘못된 가정).

또한 경험이없는 개발자는 ORM을 잘못 사용하거나 최적이 아닌 쿼리를 사용하여 데이터베이스를 무릎으로 끌어 올릴 수 있습니다.

내가 작업하는 가장 최근의 프로젝트에서는 프런트 엔드 개발자가 데이터베이스에 직접 액세스 할 수 없습니다. 주어진 데이터 세트를 리턴하는 함수에 대한 요구를 높이고 백엔드 개발자가이를 준비합니다. 프론트 엔드 개발자는 UI를 작성하고 백엔드 개발자가 작성한 함수가 제공하는 데이터를 처리합니다.

우리 개발 팀에는 우리가 사용하는 DBMS 플랫폼에 경험이있는 4 명의 데이터베이스 개발자로 구성된 하위 팀이 있습니다. 그들은 모든 SQL을 작성하거나 최소한 리뷰를 작성하고 .Net 개발자가 작성한 SQL을 코딩 표준에 맞게 변경합니다. 그들은 프로젝트 팀의 일부입니다. 프로덕션 DBA는 완전히 다른 부서에 속하며 해당 작업은 운영 중입니다. 그들은 우리의 SQL 코드 또는 스키마를 검토하지 않으며 배포조차도 스크립팅됩니다. 스크립트를 실행하기 만하면됩니다. 그들이 도움을주는 것은 성능 조정에 있습니다.