dba.se 버전 과 programmers.se 버전 의 질문 에 대한 답변과 의견 "데이터베이스 계층에 응용 프로그램 논리를 넣거나 반대하는 이유는 무엇입니까?" 일부 작업장에서 DBA와 프로그래머 사이의 차이점에 대해 매우 밝히고 있습니다.
이와 같은 문제에 대해 프로그래머와 더 잘 작업하기 위해 DBA는 어떻게 다르게 할 수 있습니까?
우리는 :
답변:
프로그래머 관점에서 볼 때, 우리가 가장 원하는 것은 데이터 계층을 설계하고 구축하는 방법에 대해 일관되고 잘 정의되고 구현 된 표준입니다. 나는 당신이 당신의 샌드 박스에서 원하는 방식으로 게임을 기꺼이하고 싶습니다. 원하는 것을 말하고 규칙을 항상 변경하지 않아야합니다. 슈퍼 프로그래머조차도 모든 사람에게 동일하게 구현되어야합니다. 당신이 그를 위해 예외를 만들면 당신은 내가 그것을 지원하고 변경하기를 원하지만 나에게 효과가없는 올바른 방법으로 다시 구현하기를 원합니다.
그런 식으로하지 말라고 멀리하지 마십시오. 나와 함께 당신이 원하는 것을, 왜 당신의 방법이 더 나은지 보여주십시오. 이해하면 매번 준수하겠습니다. 내가 그것을 얻지 못하면 준수하기가 더 어렵습니다. DBA가되고 싶지 않습니다. 나는 당신의 일을 원하지 않는 프로그래밍을 좋아하고 당신이 좋은 DBA라면 나는 당신의 가장 큰 팬이 될 것입니다.
지난 6.5 년간 MySQL DBA를 사용해 왔습니다. 또한 개발자로 16 년을 보냈으며 많은 DBA와 교류했습니다. 그들 중 많은 사람들이 실용적입니다. 그들 중 일부는 독이 있습니다. 몇몇은 DBA가 무엇을 의미하는지 전혀 모른다.
나는이 결론에 도달했다 :
기술적으로 말해서 다음과 같은 특성 중 하나 이상을 가진 DBA가 가장 적합합니다.
매우 훈련되고 지식이 풍부한 DBA는 공유하고 제공 할 것이 많습니다. 개발자가 실제로 고려하지 않은 관점에서 데이터베이스 성능을 볼 수 있습니다. 개발자는 데이터베이스에서 원하는 것을 알고 있습니다. DBA는 데이터베이스에 "폴트"하는 방법을 알고 있습니다.
성격이가는 한, 갈등, 사소함, 그리고 시기심이 항상있을 것입니다. 한 가지 확실한 점은 DBA와 개발자는 남편과 아내와 같습니다 (나는 16 년 동안 진행중인 프로젝트 [행복한 어린이 4 명]과 행복하게 결혼했습니다).
누가 남편으로 간주되고 누가 아내로 간주되는지에 관계없이 다음 원칙이 적용됩니다.
이 7 가지 원칙은 작업장, 특히 IT 영역에서 많이 적용됩니다.
모든 단계를 전달함으로써 모든 사람은 다음을 수행해야합니다.
이에 미세 관리의 여지가 없습니다. DBA 는 개발자에게 DBA처럼 생각하는 방법을 알려주지 말아야 합니다. 개발자 는 개발자 가되는 방법을 DBA 에게 알리지 말아야 합니다. 데이터베이스 성능 및 사용 에 대한 최종 결정은 DBA 에 달려 있어야합니다 . 응용 프로그램 요구 사항 에 대한 최종 결정은 개발자에게 있습니다. 이 공생 은 항상 유지되어야합니다.
원칙 # 7은 프로젝트 관리자, 팀장, 수석 개발자 인 더 높은 권위 (HA)의 적극적인 참여와 감독이 필요합니다. HA는 두 당사자가 개별적으로 작동하는 방법과 두 당사자가 함께 작동하는 방법을 더 잘 알고 있습니다. HA가 양 당사자에 대한 기본 규칙을 설정하지 않거나 HA가 당사자를 개별적으로 함께 안내하지 못하면 프로젝트는 항상 중단되어 DBA 개발자, 또는 심지어 HA.
이런 종류의 일은 장소마다 크게 다릅니다. 현재 사이트에서 개발자와 DBA 사이의 경계는 실제로 매우 흐리게 나타납니다. 우리 (DBA)도 PL / SQL을 작성하고 개발자 (개발자)는 쿼리 계획을 분석합니다. 우리는 모두 서로 다른 기술과 책임을 가진 동료라고 생각합니다. 최근 에이 회사는 DevOps 악 대차 에 뛰어 들었습니다 . 데이터베이스 커뮤니티는 이것을 전혀 이해하지 못합니다. 우리는 항상 그런 식으로 일했습니다. 말할 것도없이 우리는 이렇게 생산적으로 일하고 있습니다 : 데이터베이스 계층은 지금까지회사의 기술 스택에서 가장 신뢰할 수있는 부분 인 운영하기 쉽습니다 (DBA 팀의 기술을 통해 응용 프로그램을 심도있게 이해하고 개발자가 DBA에 노출되어 24/7/365 운영 및 방법을 이해하기 때문에) 앱을 구성하기 위해).
그러나 "잘못된"개발자에 대해 이야기 할 때의 의미를 알고 있습니다. 그는 스스로 가르쳤으며, 그 자체로는 고귀한 일이지만 그 과정에서 그는 모든 종류의 공식적인 지시에 대한 불신을 선택했습니다. 그는 자신이 모르는 것을 알지 못하고 그를 깨우려고하는 사람을 원망하며 자기 학습 기술에 대한 모욕으로 본다. 당신은 CS 유형은 항상 심하게 잘 (약 재잘되는 그 이론 물건 중 하나없이 배울 수 있기 때문에 그는 프로그래밍의 필수 스타일을 배운, 모든 사람들이 알 필요가 큰 O를그리고 유사한 이론의 비트). 그는 Java를 사용해야하기 때문에 약간의 OO도 배웠습니다. 그러나 훌륭한 데이터베이스 전문가 인 개발자 또는 DBA는 선언적 스타일로 편안한 사고, 정해진 이론, 정상적인 형태, 심지어 관계형 대수 및 미적분학을 이해할 수 있어야합니다. 이 사람들과 대화하기는 매우 어렵습니다. 웹 페이지에서 무언가를 형식화하는 방법에 국한되어 안락한 영역에서 사람들을 충격에 빠뜨릴 수있는 모든 것에 적대적이기 때문입니다. 데이터베이스를 전혀 생각하지 않는다면 테이블은 클래스와 같고 행은 객체와 같다고 생각합니다. 이 사람들은 말 그대로 SELECT * FROM TABLE결과 를 자체 코드로 필터링하고 정렬합니다.. 그들은 데이터베이스가 왜 플랫 파일보다 나은지 이해하지 못합니다. 그리고 비밀리에 관계형 데이터베이스를 사용하는 사람은 바보라고 생각하지 않습니다.
실제 예를 들어 보도록하겠습니다. 최근에 QA 이후에 문제가 발생한 경우 소프트웨어 출시 후 롤백과 관련된 문제에 대해 최근 이러한 유형 중 하나에 대해 이야기하고있었습니다. 애플리케이션을 롤백 (많은 데이터베이스에 액세스하는 것 중 하나) 할 수는 있지만 여전히 배포 된 데이터베이스로 작동 할 수 있어야한다고 설명했습니다. 그는 왜 그런지 물었고 새 테이블과 열에 실제 고객 데이터가있을 것이라고 말했습니다. 그런 다음 문제가 무엇인지 임시 테이블에 복사하면됩니다. 나는 불신으로 그를 쳐다 보았다. 고객이 전화를해서 내 계좌에서 돈이 사라 졌다고 말할 때, 우리는 그에게 무엇을 말하고, 그것이 괜찮은지, 임시 테이블에 있는지? 그는 단순히 다른 사람들의 돈을 다룰 때 책임감있는 성인처럼 행동해야한다는 것을 이해하지 못했습니다. 내가 아는 한, 그는 여전히 그렇지 않다. 그는 더 이상 우리와 함께 있지 않습니다.
MySQL 캠프는 오랫동안 이런 식으로 진행되었습니다. 그들은 거래, 외래 키 등이 필요 없다고 말했을 것입니다. 내가 생각하고있는 것 등을 알지 못했기 때문이라고 생각한 경우 (그들이 자랐을 때 조용히 추가했습니다). 이들은 ActiveRecord 나 Hibernate와 같은 ORM이 개발 된 사람들이기 때문에 SQL을 건드릴 필요없이 데이터베이스 응용 프로그램을 작성할 수 있습니다. 이러한 기술을 사용하는 것은 적기라고 생각합니다. 이것은 DBA 기술을 중요시하는 회사가 아닙니다. 그들이 정말로 원하는 것은 베이비 시터입니다 ...
프로그래머가 데이터베이스를 더 잘 이해하면 더 나은 프로그래머가되었습니다. 데이터베이스 관리자가되었을 때 이것이 더욱 중요해 졌으므로 교육이 핵심이라고 생각합니다.
DBA는 개발자를 유능한 전문가로 취급하는 개발자를 참을성있게 안내해야합니다. 클라이언트 측에서 설정된 작업과 행 단위 작업의 차이를 보여줄 때 프로그래머는 거의 없습니다. 우리는 응용 프로그램 속도, 데이터 보안, 유지 관리 성 등과 같은 동일한 목표를 공유합니다. 이것은 응용 프로그램 논리 문제뿐만 아니라 데이터베이스 상호 작용의 모든 측면에도 적용됩니다. 프로그래머는 도구를 더 잘 사용하기를 원하며 DBA가 데이터베이스 도구를 더 잘 사용하는 방법을 보여줄수록 더 많은 이점을 얻을 수 있습니다.
어떤 인프라를 지원하든 사용자를 지원해야합니다. 많은 사용자가 개발자이므로 개발자가 해당 인프라를 최대한 활용할 수 있도록 지원합니다. 이를 위해서는 서로 다른 아이디어와 관점을 염두에두고 서로를 이해해야합니다. 양측의 관점에 대한 통찰력을 확보하면 비즈니스를 개선하는 데 도움이되며 이것이 우리의 목표입니다. IT가 비즈니스를 최대한 효과적으로 지원하도록하십시오.
많은 조직에서 신 모드로 실행되는 일부 dba 유형을 봅니다. 대부분의 경우 역량이 측정되는 경우 점수가 매겨지지 않는 경우가 많습니다 ..... 종종 그들은 지식의 부족을 단어의 벽 뒤에 숨 깁니다.
내 의견으로는 그것은 '프로그래머 친화적'이되는 것이 전문적이되는 것과는 아무 관련이 없다. dba의 경우 가용성, 확장 성, 복구 가능성 및 성능과 같은 일반적인 목표를 잃지 않고 도움이된다면 결정을 내릴 때 왜 우리가하는 일을하고 준비해야하는지 설명 할 수 있어야합니다. 프로그래머에게는 dba와 통신하고 때로는 dba를 가르치고 때로는 dba로부터 배우기 위해 의사 소통해야 함을 의미합니다. 이것에 대한 나의 좌우명은 : 내가 배우지 않는 첫날이 관이 내 머리 위로 닫히는 날이되게하십시오. 개발자 및 dba와 팀을 결합한 정상적인 협업은 일을 더 쉽게 만들어줍니다.
문제의 일부는 원근이라고 생각합니다. Dbas와 데이터 분석가 및 데이터베이스 개발자는 시간이 지남에 따라 데이터를 처리해야합니다. 응용 프로그램 개발자는 프로덕션으로 보낼 때 작업을 수행하는 방법에 관심이 있습니다. 데이터가 배포 될 때 오류가없는 한 6 개월 안에 데이터가 어떻게 보일지 걱정하지 않습니다.
그러나 데이터 사람들은 데이터의 무결성을 잃거나 중복 레코드가 삽입되게하는 근시안적인 결정의 결과에 따라 생활해야하며 데이터가 왜 나쁜지 설명해야합니다. DBA는 천 개의 레코드 만있을 때 제대로 작동했지만 이제 100,000,000 개의 레코드로 몇 시간이 걸리는 프로세스의 성능 문제를 처리해야합니다.
데이터베이스는 리팩토링하기가 더 어렵 기 때문에 DBA는 처음으로 올바르게 처리하는 데 관심이 있습니다. 개발자들은 도로를 리팩토링하는 데 아무런 문제가 없다고 생각합니다.
개발자들은 데이터베이스가 객체 지향적 인 것처럼 작동하도록하는 데 아무런 문제가 없다고 데이터베이스 사람들은 데이터를 저장하거나 얻는 가장 효과적이고 효율적인 방법이 아니라는 것을 알고 있습니다.
응용 프로그램 개발자는 종종 작은 레코드 하위 집합 만 다루지 만 큰 데이터 가져 오기 / 내보내기 또는보고는 다루지 않습니다. 하나의 레코드를 입력하는 데 잘 작동하는 것은 백만 가져 오기에 대해 이야기 할 때 작동하지 않습니다. 응용 프로그램의 비즈니스 논리 (보고 응용 프로그램에서 종종 액세스 할 수 없음)는 보고서 작성기가 한 번에 한 레코드 씩 화면에 표시되는 것과 같은 백만 개의 레코드에 대해 동일한 결과를 얻는 데 도움이되지 않습니다.
문제의 또 다른 부분은 양쪽에 대한 무례 함입니다. 데이터 작업이 어렵거나 흥미롭지 않다고 생각하고 자신의 세계에서 해킹 할 수없는 경우에만이 작업을 수행 할 것이라고 믿는 몇 명의 응용 프로그램 개발자를 만났습니다. 사람들은 마치 멍청하고 쓸모없는 것처럼 대우받는 것에 반응하지 않는 경향이 있습니다. 반면에 일부 DBA는 응용 프로그램 개발자를 무례하게 대하는 경향이 있으며 개발자가 데이터베이스에 대해 수행중인 작업을 우선 순위가 낮은 (복잡한 프로덕션 데이터베이스가있는 경우) 검토하는 경향이 있습니다. 그들은 응답을 거부하거나 거부 할 수 있습니다. DBA가 2 주 후에 다시 검토 할 때까지 프로젝트 전체를 보류하고 싶은 사람은 누구입니까? 그리고 그는 그것이 당신에게 받아 들일 수 없다고 말하고 당신은 모든 것을 다시 써야합니까?
SQL Server (1998)를 시작한 이후 몇 년 동안 많은 개발자들에게 업무 수행 방법을 알려주었습니다. 그것은 그들이 그 흥미로운 모두 알고 더 나보다뿐만 아니라있는 최고의 .NET 개발자. 사실, 그들은 건축가 이기도하고 코드 원숭이보다 더 큰 일을해야합니다.
아마도 그것은 저의 잘못된 태도 일 것입니다. 그러나 그것은 많은 상점에서 매우 일반적인 개발자 태도입니다. 그들은 서로에게도 그렇게합니다. 동료 리뷰를 제안 할 때 싸움이 시작되는 것을보십시오.
수정 사항을 다른 답변으로 남겨 두겠습니다 (지금까지 2에 100 % 동의합니다). 경영 및 상점 문화 도 협력을 지원하고 육성 해야한다고 덧붙입니다.
개발자로서 필요한 것은 내가 원하는 것을 어떻게 전달하길 원하는지 아는 것입니다. 내가 어리석은 것을 요구하고 있다면, 당신이 나에게 말해 줄 필요가 있습니다. 당신이 그렇게 말하면, 당신은 성실성에 대한 기록이 있기 때문에 그것을 믿을 것입니다. 내가 원하는 것을 이해하지 못하면 시간을내어 내가 생각하는 바를 설명해 주시면 시간을내어 들어 보겠습니다.
... 공통 주제, 오른쪽 ... 통신 ... 통신 ... 통신.
그것을 넣는 더 좋은 방법은 없습니다. "DBA가 나에게 할 수 없다고 말한 것 같습니다. 지난 번에 그에게 틀렸다는 것이 확실합니다." DBA는 "개발자가 사양을 변경할 때마다 내가해야 할 일을 이해하지 못하기 때문에"진드기 시작합니다.
@Rolando가 언급했듯이 개발자와 DBA는 서로를 이해해야합니다. 모든 것이 다 내려 오면, 우리는 "Ones & Zeros"라고 말합니다. 우리에게는 2 가지 책임 영역이 있습니다. DBA에는 데이터가 있으며 개발자는 나머지 컴퓨터를 얻습니다. 그러나 데이터가 없으면 프로그래머는 실제로 할 일이 많지 않습니다.
우리는 DBA를 가지고 있지 않으며 때때로 고통 스럽습니다. 10 년 전에 DBA가되고 싶었던 그 부분은 우리가하는 일을 볼 때 울부 짖을 것입니다. 우리가 내일 DBA를 고용한다면, 나는 그 / 그녀가 걸었던 바로 그 키스를 할 것이라고 생각합니다.
일부 회사에서는 아마도 많은 제품 개발에서 컴파일 된 언어로 작성하지 않는 사람을 무시하는 경향이 있습니다. 네트워크 관리자, DBA, 시스템 관리자, 사용자 지원 등은 각자 실사를 완료해야하기 때문에 출시시기가 왔습니다. 환경의 주요 측면을 고려하지 않았기 때문에 종종 두통이 있습니다. 이것은 자연스럽게 팀 사이에 긴장을 유발합니다.
누가 여기에서 비난해야합니까? 의사 소통.
개발자는 환경 코드가 배포 될 것임을 이해해야합니다. 사람들에게 적응하려면 공정한 경고를 받아야합니다. 어떤 이유로 든 환경 (보안, 장비, 정책)에 적응할 수없는 경우 소프트웨어를 조정해야합니다. 이것이 설계 및 구현 프로세스 중에 발생하면 모두 행복합니다. 배포 시간까지 시작되지 않으면 다치게됩니다.
그렇습니다. 팀은 서로 대화하고 듣고 있어야하지만 프로젝트 / 제품 관리자는 이러한 상황이 발생할 수있는 환경을 만들어야합니다.
나는 운이 좋았습니다. 제가 일한 대부분의 장소에서 상호 존중과 의사 소통은 문화의 일부였습니다.
좋은 DBA가 이해해야 할 것은 데이터의 정치입니다. 나는 몇 년 동안 노련한 프로그래머들과 몇몇 초안 DBA들에게 데이터베이스 프로그래밍과 디자인을 가르쳤다. 정기적으로 제기되는 한 가지 질문은 다음과 같습니다. 내 상점에있는 모든 데이터베이스가 어떻게 정치적인가?
내 표준 답변은 다음과 같습니다. 데이터베이스가 유용하면 데이터를 공유하고 있습니다. 데이터를 공유하고 있다면 힘을 공유하는 것입니다. 권력이 공유되면 정치가 일어납니다.
정치를 좋아하는지 아니면 정치를 싫어하는지는 중요하지 않습니다. 좋은 데이터베이스 작업을 수행하려면 익숙해 지십시오.
덧붙여서, 여러분 중 일부는 개발 환경에서만 일했습니다. 펜스의 프로덕션 측면에서 작업하고 개발자와 거의 상호 작용하지 않는 DBA가 있습니다. 생산에있어 정치가 덜 있다고 생각할 수도 있습니다. 더있다. 대규모 프로덕션 데이터베이스는 전사적이며 미션 크리티컬 한 경향이 있습니다.