생산 데이터를 바탕으로 개발하는 것이 좋지 않습니까?

나는 항상 생산 데이터를 바탕 으로 개발하는 것이 나쁜 습관이라고 들었습니다 . 주로 Dev> Stage> Production 모델 로 옮기는 과정에 있습니다. 주로 최소한의 기술을 가진 새로운 직원이 있고 오히려 그를 갖지 않기 때문입니다. 아직 생산 데이터로 직접 작업하십시오.

그러나 오랫동안 여기 저기에서 발생하는 몇 가지 오류, 철자 문제, 잘못된 대체 텍스트, 잘못된 위치를 가리키는 링크와 같은 것을 제외하고는 최소한의 두통으로 생산 데이터로 직접 작업했습니다. 이것은 실제 데이터 작업이 아니라 내 동료 평가가 부족한 것으로 보입니다.

라이브 사이트에서 개발하는 것이 왜 그렇게 나쁜 습관입니까?

개발 중에 기존 데이터베이스 테이블 을 포함 INSERT하거나 UPDATE기존 데이터베이스 테이블 에서 SQL 명령을 실행하는 경우 해당 데이터베이스 테이블이 미션 크리티컬 한 정도까지 위험을 감수해야합니다.

일부 장소는 일주일에 한 번 또는 개발자 요청에 따라 일정한 간격으로 프로덕션 데이터를 개발 데이터베이스에 동기화하므로 새로운 데이터를 개발할 수 있습니다.

그러나 프로덕션 데이터가 현재 수행중인 작업으로 인해 위험에 처하지 않는 경우 (예 : 단순히 일부 데이터보기 만 개발하는 경우) 별 문제가되지 않습니다. 이제 테이블 스캔을 수행하는 보고서를 실행중인 경우 테이블을 잠글 가능성이 있으며 기존 사용자가 영향을받습니다.

"공식적인"DBA가없는 경우, 데이터베이스 관리자에게 이의를 제기하고 싶습니다. 나 자신도 개발 데이터베이스를 만들 수있을 정도로 간단합니다. 팀에서는 매우 중요합니다. 단 하나의 데이터베이스 만 가져야한다면 개발 데이터베이스 테이블을 접두사로 사용 DEV_하는 것이 좋습니다. 예, 약간의 코드 변경이 필요하지만 개발시 개발 $debug = true등에서 일부 변수를 추가하는 것이 일반적으로 노력할 가치가 있습니다.

이것에 접근하는 많은 방법. 상황에 따라 매우 다릅니다.

프로덕션 서버의 프로덕션 데이터에 대해 개발하지 않으려 고합니다. 몇 가지 큰 이유가 있습니다.

1. 개발은 프로덕션 박스의 속도를 늦추고 취약점을 만듭니다. 컴퓨터를 잠금 해제 상태로두고 떠나면 어떻게됩니까?
2. 실수를하면 사이트를 방문하는 사람들이이를 볼 수 있습니다.
3. 데이터베이스의 트랜잭션 내부에서 데이터 업데이트를 수행하고 즉시 커밋하지 않거나 트랜잭션을 완료하는 데 시간이 걸리는 경우 관련된 모든 테이블을 잠그면 시간 초과가 발생할 수 있습니다 .
4. 일부 데이터베이스 시스템, 특히 SQL Server는 SELECT 문에서만 테이블 잠금을 수행합니다! 이는 의도하지 않게 사람들에게 사이트 시간 초과 또는 오류 페이지를 제공 할 수 있음을 의미합니다.

가능하다면 라이브 박스에서 개발 작업을하지 않을 것입니다. 가장 좋은 방법은 데이터베이스와 페이지를 백업하고 복사본으로 작업 한 다음 업데이트를 푸시하는 것입니다. 많은 도움이 된 한 가지 도구는 Msft의 SyncToy입니다.

글쎄, 당신은 정말로 데이터를 망칠 수 있습니다. where 절을 생략한다고 상상해보십시오. 시간별 백업이 있어도 해결하기가 어려울 수 있습니다.

안전 벨트없이 운전하지 않으면 생산 데이터를 개발하지 마십시오. 안전 문제 일뿐입니다.

사용 가능한 프로덕션 데이터가있는 경우 테스트에 사용하는 것이 합리적이지만 해당 데이터의 사본이있는 별도의 테스트 데이터베이스를 사용하십시오. 그렇지 않으면 많은 "blabla"테스트 레코드에는 많은 것이 작동하지만 실제 시나리오에는 적용되지 않습니다.

라이브 프로덕션 데이터를 개발하기 위해서는 머피의 법칙을 기억하십시오. "실수 할 수있는 것은 잘못 될 것입니다."