데이터베이스를 설계하는 것은 프로그래머의 일입니까?

저는 지난 6 년간 프로그래머였습니다. 내 경력을 통해 많은 웹 응용 프로그램에서 일했습니다.

대부분의 경우, 데이터베이스가 필요할 때는 데이터베이스를 우리 (프로그래머)에게 주거나 기존 데이터베이스를 작업해야했습니다. 그렇지 않다면 데이터베이스를 직접 작성하여 설계해야했지만 그렇게 힘들지는 않았습니다.

그러나 프로그래머로서 데이터가 매우 중요하고 복잡한 데이터 모델로 복잡한 요구 사항이있는 새 응용 프로그램을 빌드해야 할 때 전체 데이터베이스를 처음부터 새로 만들어야합니까?

전문가가 앱을 완성하는 것이 앱과 회사의 최선의 이익이 아닙니까?

데이터베이스 디자인에서 벗어나려고 노력하지는 않지만 제대로 이해하는 것이 중요합니다.

우선, 프로젝트 관리자가 지시하면 그것은 당신의 일입니다. 소규모 회사에는 종종 전임 DB 전문가가 없습니다. 어쨌든 개발자와 DB 전문가 사이에는 분명한 차이가 없으며 그렇게해서는 안됩니다. 좋은 개발자는 DB에 대해 상당한 지식을 가지고 있으며 좋은 DBA는 적어도 DB의 언어로 저장 프로 시저를 코딩하는 방법을 알고 있습니다 .

DB 디자인은 응용 프로그램의 핵심 부분이지만 다른 많은 코드가 의존하는 다른 중심 부분보다 "올바르게"얻는 것이 더 중요하지 않습니다.

코드와 마찬가지로 일주일 동안 열심히 일하고 열심히 생각한 다음 절대 변경할 필요가없는 완벽한 디자인을 작성해야한다는 전문가가 있다는 착각은 환상입니다. DB 디자인은 애플리케이션 개발 중에 변경 될 수 있습니다.

따라서 프로그래머 (DB를 잘 이해하는 사람)가 설계 한 DB를 갖는 것이 실제로 도움이됩니다. DB 만 이해하고 나머지 개발 작업과는 아무런 관련이없는 사람이 수행하는 것보다 확실히 낫습니다.

프로그래머가 데이터베이스를 만드는 것이 일반적입니다. 매우 흔한. 불행히도 많은 프로그래머는 DB에 경험이 없습니다. 그들은 빅 데이터, 데이터 마트, 스타 스키마 등의 개념에 대해보고하는 방법을 이해하지 못합니다. 일부는 정규화의 기본 사항을 이해하지 못합니다.

한 사람이 전문가 수준에서 모든 것을 할 수있는 기술을 보유하고 있다면 매우 훌륭한 제품이됩니다. 한 남자 군대는 10 남자 팀이 1000 배의 품질로 짧은 시간 안에 할 수있는 일을 할 수 있습니다. 과장이 아닙니다.

프로그래머가 자신이하는 일을 알고 있다고 가정 할 때 프로그래머가 적은 사람들을 위해하는 것이 가장 좋습니다. 물론 수천 건의 실패도 있습니다.

흥미로운 질문-대부분의 괜찮은 개발자가 관계형 데이터베이스를 올바르게 구성하는 방법, 즉 표준화 된 스키마를 생성하고 경험과 공통 패턴을 기반으로 합리적으로 만들 수 있어야한다고 말하는 강력한 주장이 있습니다. 데이터 구조화 방법에 대한 결정 (주로 나에게는 명백하지만 모든 사람이 그렇게 생각하지는 않는다는 것을 알고 있습니다).

또한 Entity Framework Code-first를 살펴보면 저수준 데이터 모델을 구축 할 때와 동일한 생각이 합리적인 스키마를 만들거나 적어도 하나를 암시한다고 제안합니다.

따라서 아니요, 데이터베이스 스키마를 디자인하려면 데이터베이스 전문가가 필요하다고 생각하지 않습니다. 적어도 중소형 데이터베이스 (내가 작업 한 것)에는 적합하지 않습니다.

문제는 좋은 (또는 최소한 적절한) 스키마를 설계하는 것이 전체 스토리가 아니라는 것입니다. 특히 데이터베이스를 확장해야하는 경우에는 그렇지 않습니다. DBA가 가져온 "부가가치"는 인덱스, 스토리지 구성, 데이터베이스 유지 관리 (파일 크기 확인, 인덱스 재구성 등)와 같은 기본 스키마 권한 이외의 것을 얻는 것입니다. 사용자 및 역할 등이 있습니다.

훌륭한 프로그래머는 다양한 기술 포트폴리오를 가져와야합니다. [선택 언어 삽입] 코더 이상이어야하며 해당 포트폴리오의 데이터베이스에 대한 이해도 포함합니다.

합리적인 관계형 데이터베이스를 설계하는 능력은 주니어가 아닌 프로그래머에게는 필수적이라고 생각합니다.

그러나 특히 대규모 응용 프로그램의 경우 데이터베이스 (스키마, 인덱싱 등)를 처음에 "올바르게"얻는 것이 중요합니다. 회사가 숙련 된 DBA에 액세스 할 수있는 경우 해당 작업을 수행해야합니다. 일반적으로 그들은 더 자격이 될 것입니다. 클라이언트 측에서 데이터베이스에 액세스하고 작업 할 수석 개발자와 함께 잠재적 인 검토 / 토론을 수행하여 놀라운 일이 없도록해야합니다. DBA가 없으면 프로그래머가 데이터베이스를 설계합니다.

여기에 두 가지 질문이 있습니다.

• 데이터베이스 개발자는 비즈니스 로직을 모델링해야합니까?
• 데이터베이스에 데이터를 유지하는 방법을 알아야합니까?

비즈니스 로직

• 비즈니스 로직은 데이터베이스에 없습니다. 시스템 내 다른 레이어와 독립적이어야하는 개념적 모델입니다.

• 항상 한 데이터베이스를 다른 데이터베이스로 교체하거나 잠재적 성능 문제를 해결하기 위해 NoSQL 솔루션을 사용하기로 결정할 수도 있습니다.

• 데이터베이스 개발자는 모델링 프로세스 중에 관여 할 수 있지만 일반적으로 문제 영역을 완전히 이해 한 사람이 수행합니다. 우리 조직에서는 서버 측 개발자가이를 수행합니다.

• 많은 사람들이 데이터베이스가 애플리케이션의 기초라고 생각합니다. 기초가 열악하면 시스템이 무너집니다. 나는 이것에 동의하지 않습니다. 데이터베이스를 항상 교체 할 수있는 저장 매체로보고 있습니다.

지속 데이터

• SQL 및 NoSQL 솔루션을 포함하여 다른 저장 매체에 데이터를 유지하는 방법을 알아야합니다.

• 필요한 전문 지식 수준은 작업중인 시스템의 크기에 따라 다릅니다.

• 대기업은 일반적으로 성능, 확장 성 및 보안 관련 요구 사항을 해결하기 위해 전문가를 고용 할 때 소규모 지식을 보유해야합니다.

요약하면 다음과 같습니다.

• 도메인 모델은 데이터베이스가 아니라 시스템의 기초입니다.

• 소규모 회사에서 비교적 소규모 프로젝트를 수행하는 경우 데이터베이스를 직접 설계해야합니다.

• 엔터프라이즈 시스템에서 대기업에 근무하는 경우 도메인 전문가에게 작업을 전달하는 것이 더 합리적입니다.