Marjan Venema의 답변은 기술적으로 유효하며 가능하면 따라야합니다. Alas, Marjan은 이론 가나 관점을 깨끗하게 만드는 것을 좋아 하는 순수 데이터베이스 관리자 의 관점에서 대답합니다 . 실제로 비즈니스 제약으로 인해 깨끗한 방식으로 작업을 수행하지 못하는 경우가 있습니다.

다음과 같은 경우를 상상해보십시오.

1. 소프트웨어 제품에 데이터베이스의 일부 데이터가 일치하지 않는다고 생각되는 것을 감지하면 작동을 멈추게하는 버그가 있습니다.

2. 애플리케이션에서 버그를 잠재적으로 수정할 수있는 모든 개발자는 접근 할 수 없습니다.

3. 이 회사는 현재 시간당 수천 달러를 잃고 있습니다 (예 : $ 6 000, 즉 분당 $ 100).

4. 버그는 여러 테이블에 영향을 미치며 그 중 하나는 거대하며 스키마 자체가 아닌 데이터 자체에만 영향을 미칩니다.

5. 버그를 피하기 위해 데이터를 약간 실험 해보아야합니다.

6. 데이터베이스가 커서 백업을 가져 오거나 복원하는 데 3 시간이 걸립니다.

7. 마지막 전체 백업은 3 주 전에 수행되었습니다. 일일 증분 백업도 있으며 마지막 일일 증분 백업은 14 시간 전에 수행되었습니다.

8. 데이터베이스 백업은 안정적인 것으로 간주됩니다. 최근에 포함해서

9. 14 시간의 데이터 손실은 허용되지 않지만 1 ~ 2 시간의 데이터 손실은

10. 준비 환경은 6 개월 전에 마지막으로 사용되었습니다. 최신 상태가 아닌 것 같습니다. 설정하는 데 몇 시간이 걸릴 수 있습니다.

11. 데이터베이스는 Microsoft SQL Server 2008 Enterprise입니다.

작업을 수행하는 깨끗한 방법은 다음과 같습니다.

1. 준비 환경에서 백업을 복원합니다.

2. 거기서 실험 해

3. 마지막 스크립트를 두 번 확인하십시오.

4. 프로덕션 서버에서 스크립트를 실행하십시오.

첫 번째 단계는 회사에 18,000 달러가 소요됩니다. 세 번째 단계를 완벽하게 수행하면 위험이 매우 낮아 지지만 극심한 압박을 받으면 위험이 훨씬 높아집니다. 스테이징에서 완벽하게 작동하는 스크립트가 생겨 프로덕션 데이터베이스를 망칠 수 있습니다.

대신 다음과 같이 할 수 있습니다.

1. 스냅 샷 생성 (Microsoft SQL Server는이를 지원하며 백업하는 데 1 시간이 걸리는 데이터베이스의 스냅 샷을 되 돌리는 데 몇 초도 걸리지 않습니다. 다른 데이터베이스 제품도 스냅 샷을 지원한다고 생각합니다),

2. 프로덕션 데이터베이스에서 직접 실험하여 문제가 발생하면 스냅 샷으로 되돌립니다.

순수 주의자는 데이터베이스를 깨끗한 방식으로 수정하고 회사의 2 만 달러 이상을 낭비하면서 시간 압력을 가하면 문제를 해결할 위험이 있지만 비즈니스 제약 조건을 고려하는 데이터베이스 관리자는 데이터베이스를 어떤 방식 으로든 수정합니다. 이렇게하면 위험을 최소화하면서 (스냅 샷 덕분에) 신속하게 수행 할 수 있습니다.

결론

나는 순수 주의자이며, 깨끗하지 않은 방식으로 일을하는 것을 싫어합니다. 개발자는 수정 한 코드를 리팩터링하고 리팩터링 할 수없는 어려운 부분에 대해 언급하고 코드베이스를 단위 테스트하고 코드 검토를 수행합니다. 그러나 나는 또한 당신이 깨끗하게 일하고 다음날 해고당하는 상황이나 빠른 해킹을 통해 위험과 재정적 영향을 최소화하는 상황을 고려합니다.

일부 IT 직원이 회사를 위해 수천 달러의 손실을 입히는 동안 청결 을 위해 깨끗하게 일하기 를 원한다면이 IT 직원은 자신의 직업에 대해 깊은 오해를 가지고 있습니다.

답변