새로운 기능을 처리하기 위해 데이터베이스 리팩토링 또는 업그레이드

데이터베이스 스키마 질문에 대한 여러 응답 은 현재 요구 사항의 일부가 아닌 기능에 대해 데이터베이스를 정규화하기위한 추가 테이블을 제안했습니다 (직원 / 사용자와 서로 다른 부서 간의 다 대다 관계를 허용하기위한 UserDepartment 테이블). 에 속하는.).

정규화에 반대하지 않습니다. 데이터베이스 디자인과 관련하여 미래에 누군가가 원할 '확실한'기능을 포함시키려는 강력한 추진력이 있습니다. 오버 엔지니어링 경향이있는 기능을 수용하기 위해 데이터베이스에 테이블 / 필드를 추가하는 것이 너무 어렵습니까? 필요한 경우 나머지 앱처럼 리팩터링되거나 업그레이드되지 않습니까? 재실행하는 것은 결코 재미가 없지만 한 테이블에서 새 테이블로 데이터를 이동할 수 있습니다. 이 사고 방식이 어디에서 끝나는 지 확실하지 않습니다.

편집 : 이것에 대한 혐오가 너무 많아서 얼마나 많은 프로젝트가 급격한 데이터베이스 변경이 필요하거나 새 테이블 대신 DepartmentID2 필드를 추가하는 것과 같이 표준화되지 않은 접근 방식을 추가하지 않는지 궁금합니다. 직원을 위해 여러 부서가 필요하다는 것은 일반적인 도메인 문제입니다. 나는 다 대다 관계로 가득 찬 많은 데이터베이스 스키마를 보지 못했습니다.

데이터베이스 리팩토링에 관한 책이 있습니다. 코드 리팩토링과 마찬가지로 데이터베이스 리팩토링을 수행하는 표준 방법이 있습니다. 유일한 차이점은 코드 리팩토링을 수행 할 때 객체 / 코드의 상태를 고려할 필요가 없지만 데이터베이스에서는 데이터를 고려해야한다는 점입니다. ).

데이터베이스 리팩토링에 대한 자세한 내용은 여기를 참조하십시오 .

코드 리팩토링은 쉽습니다. 코드를 변경하고 회귀 테스트를 실행하면됩니다.

데이터베이스 리팩토링은 어렵습니다. (거의 많은 양의) 데이터를 옮기고, 삭제되지 않았는지 확인하고, 새로운 스키마에서 제약 조건이 유지되는지 확인하십시오. 또한 데이터에 대한 감사 요구 사항이있는 경우 데이터가 다르게 구성되는 이유를 설명하고 사전 리포터 데이터와 리팩터링 후 데이터를 일치시킬 수 있어야합니다. 또한 이전 백업 중 어느 것도 새 스키마와 일치하지 않으므로 또 다른 위험이 있습니다.

무서운 것들.

오버 엔지니어링에 많은 시간을 투자하고 미래에 상당한 시간을 절약 할 수있는 충분한 기능을 추가하기 위해 약간의 시간을 투자하는 것 사이에는 미세한 차이가 있습니다.

이론에 따르면 두 테이블 사이의 다 대다 관계를 지원하는 링크 테이블을 포함하면 실제로 데이터에 다 대다 관계 만 존재하더라도 모든 사람이 SQL을 다음과 같은 방식으로 작성합니다. 다 대 다수는 모든 것이 "그냥 작동"할 수 있도록 지원됩니다.

실제로 나는 이것이 사실이라는 것을 일반적으로 알지 못했지만 SQL이 다른 것보다 많은 것을 지원하는 데 필요한 것에 더 가깝다고 생각합니다.

그러나 귀하의 질문에 구체적으로 설명하기 위해 실제로 는 일대 다에서 다 대다로의 관계를 변환하는 상당한 고통이 있습니다. 그 이유는 SQL이 개체와 동일한 종류의 캡슐화 목표로 설계 되지 않았 으며 대부분의 쿼리는 비즈니스 계층의 개체가 가시성을 갖는 것이 편한 것보다 데이터베이스 계층에서 더 많은 테이블을 사용하기 때문입니다.

따라서 다 대 다 관계에 대한 변경은 원래 2 개의 테이블이 포함 된 모든 쿼리에 영향을 미치며, 종종 비즈니스 계층에서 발생하는 것보다 훨씬 광범위한 계단식 효과입니다. 그래서 사람들은 이런 일이 발생하지 않도록 상당한 노력을 기울입니다.

IMHO 관계형 대수를 지정하기 위해 SQL보다 언어가 더 좋으면 필요하지 않습니다. 쿼리의 모든 테이블에 대한 가시성이 필요하지 않은 개체별로 SQL 쿼리를 하나씩 구축하는 것이 가능하다면 이런 일이 발생하지 않습니다. LINQ (SQL 또는 엔티티)와 같은 것들이이 문제를 해결하려고 시도하지만 매우 복잡한 솔루션이며 최적화하기가 어렵습니다 (그리고 LINQ가 언급되고 매번 신음하는 DBA 사용자 그룹에 왔습니다). 나는 일급 관계형 대수 함수로 보편적으로 지원되는 데이터베이스 언어를 꿈꿉니다 ...

한편, 일대 다에서 다 대다로 리팩토링 할 수 있지만 많은 작업이 필요할 수 있습니다.

필자는 일반적으로 PHB에이 방법을 설명합니다. 코드는 벽과 지붕이며 데이터베이스는 기초입니다.

벽을 옮기고 지붕을 바꿀 수 있습니다. 기초를 바꾸려면 벽과 지붕을 파고 재건해야합니다.

경험이 부족한 개발자 (및 대학 교수)가 말하는 것은 "과잉 엔지니어링"은 경험이 풍부한 개발자가 "미래 교정"이라고합니다. 스펙에 명시된 내용에도 불구하고 ALM 중에 변경 될 사항 또는 성능 문제가 발생할 위치를 알고 있으므로 테이블 구조를 바로 시작하려고합니다.

고객 서버에 업데이트 스크립트를 롤아웃하는 것은 쉬운 일이 아니며 각 고객의 DBA는 모든 것을 3 번 확인하려고합니다. 일부 추가 열과 테이블은 결국 그렇게 나쁘지 않습니다.

관계는 1-1이지만, 경우에 일반적입니다 수 있습니다 미래에 많은 많은 후 많은에 그것은 많은 수 있도록합니다.

직원 / 부서가 전형적인 예입니다. 대부분의 소기업에서 이것은 사실상 대부분 일대 다 관계 입니다. 그러나 거의 항상 상황이 많을 수 있습니다. 엔지니어 중 한 명이 경영진으로 옮겨 가지만 엔지니어링 중이거나 자신의 영업 사원 중 한 명이 이사하는 동안 개발 한 제품을 지원할 책임은 여전히 ​​있습니다 제품 개발을 담당하지만 중요한 고객과 긴밀한 관계를 유지하고 있기 때문에 여전히 해당 고객의 영업 사원입니다.

일대 다가 다 대다로 구현되는 경우 비용이 많이 들지 않지만, 다대 다를 지원하기 위해 데이터베이스와 애플리케이션을 리팩토링하는 것은 비용이 많이 들고 어려움이 따릅니다.

소프트웨어 디자인을 보는 방법에는 두 가지가 있으며 전술적 관점 또는 전략적 관점입니다. 각각의 장점과 단점이 있습니다.

OO 소프트웨어 수정이 여전히 고통 스럽지만, 코딩 부분은 어려울뿐만 아니라, 불만 사항 환경 (현재 기술 상태가 제공됨)에서 생산 변경을 촉진하는 프로세스는 비현실적인 대형 시스템에서 비현실적입니다. 연중 무휴 24 시간 근무.

" 가능한 경우 전략적으로 공유 소프트웨어 아티팩트를 설계 하십시오"라는 내 원칙을 따릅니다 .-이것은 어떤 방식 으로든 YAGNI 원칙에 어긋나는 것처럼 들릴 수 있지만 이것이 제 의견입니다. 이 접근 방식은 복잡성 및 리소스 비용에 대한 재 작업을 줄입니다.

귀하의 경우, 새로운 접합 테이블을 추가하는 데 필요한 활동에는 설계, 설계 승인, 스키마 변경, 3 개의 테이블에 대한 CRUD에 대한 몇 가지 방법 재 작성 (일부 읽기 제외), 인덱스 작성,에 대한 GUI 작성이 포함됩니다. 새 테이블에 대한 CRUD, 사용자가 새 테이블 작성, 업데이트 등에서 PK를 선택할 수 있도록합니다. 아, 물론 단위 테스트, 사용자 승인 테스트, 시스템 테스트 및 프로덕션 프로모션을 잊지 마십시오.

이것으로 충분하지 않으면 실제 악몽은 정보 손실에서 비롯됩니다. 접합 테이블을 시작하지 않고 직원과 부서 간의 연관 / 분리가 발생한 날짜를 캡처하기로 결정한 경우 접합 테이블의 날짜를 자동으로 채울 수 없습니다. 수동으로 입력해야합니다 (데이터가있는 경우).

따라서 처음부터 이것을 예측하는 것이 좋습니다.

Matthew가 말했듯이 데이터 관리도 고려해야하기 때문에 데이터베이스에 대한 리팩토링 / 변경 데이터베이스가 종종 소프트웨어에 비해 더 복잡합니다. 적절한 데이터베이스 단위 테스트 스위트를 확보하고 'DB API'(sprocs / views 등)를 사용하여 기본 스키마에서 클라이언트 애플리케이션을 분리하는 등의 기술이 있습니다.