개발자가 테이블, 뷰, 저장 프로 시저 및 함수를 추가하여 타사 데이터베이스 (MS SQL)를 확장 한 상황이 있습니다. 최근에 벤더가 데이터베이스에 업데이트를 발행했을 때 모든 사용자 지정 개체가 삭제되었습니다. 문제는 이제 우리가 제 3 자 데이터베이스를 확장 할 수 있지만 향후 업데이트에서 우리의 객체를 안전하게 유지할 수있는 모범 사례는 무엇입니까? 내 첫 번째 생각은 별도의 데이터베이스를 만드는 것이지만, 나는 테스트에서 생산에 이르기까지 데이터베이스 변경을 촉진하는 문제를 일으킬 수있는 모든 참조를 원래 데이터베이스로 완전히 한정하는 작업에 전념해야합니다.타사 데이터베이스 확장을위한 우수 사례?
유일하게 안전한 방법은 다른 데이터베이스입니다.
permsiisons를 설정하여 항목을 삭제할 수는 있지만 공급 업체가 될 확률은 SA 액세스입니다.
SQL Server 2005 이상을 사용하는 경우 다른 스키마를 사용해 볼 수도 있지만 개발자가 모든 항목을 삭제할 수 있습니다.
가장 좋은 방법은 구입 한 타사 제품의 개발자와 대화하는 것입니다. 그들은 제품을 확장하도록 설계하지 않았을 수 있습니다. 확장 성을 향상시킬 수 있는지 알아보기 위해 그들과 대화해야합니다.
그들은 데이터베이스를 확장 할 수있는 방법을 제한하려고 할 것입니다. 일부 확장 프로그램은 신중하게 조정 된 데이터베이스에서 문제를 일으킬 수 있습니다.
.. 그리고 다음 개정판, 펑! 모든 것이 난독 화되거나 암호화됩니다! 공급 업체가 사용자 정의 변경에 대해 요금을 부과하는지 또는 통조림 제품 만 판매하는지에 따라 다릅니다. 기술 지원이 무효화 될 수 있습니다. 고객이 내 DB를 망쳐 놓고있는 제품을 지원하고 싶지 않습니다. –
이 경우 우리는 객체를 추가 만하고 어떤 벤더 코드도 변경하지 마십시오 –
@Eric Watkins, 즉 'wooops, oh no, call support!'직전에 말한 것입니다 –
계약을 위반하지 않았는지 확인하려면 공급 업체와의 사용권 계약도 확인해야합니다. 일부 소프트웨어 공급 업체는 명시 적으로 클라이언트가 사용권 계약에서 스키마를 변경하지 못하게합니다. 많은 기업이 데이터를 소유한다는 입장을 취하고 있지만 스키마는 지적 재산입니다. 또한 스키마를 "간단하게"변경해도 응용 프로그램 자체에 문제가 발생할 수 있습니다. 공급 업체는 사이트에 설치된 비트가 실제로 배송되고 테스트 된 것과 동일한 수준임을 어느 정도 확신해야합니다.
많은 경우, 기성품 응용 프로그램을 무단으로 변경하면 보증/지원 계약이 무효화됩니다 –
테스트 및 프로덕션에 대한 데이터베이스 간 참조 문제를 처리 할 수 있도록 별칭을 사용할 수 있습니까? –