[Sequel Safe] SQL 서버 Login 권한 정책 및 물리 모델 변경 제약

I. Sequel Safe에서 DBA로 지정된 사용자만이 모델을 수정할 수 있습니다.

먼저 Sequel Safe에 국한하여 다음과 같이 용어를 재 정의합니다.

1. DBA
1. SQLSafe.dbo.DBAs 테이블에 등록되어 있는 Login을 말합니다.
2. 모델러 & SQL개발을 담당하는 sysadmin에 속한 사람을 등록합니다.
   
   
2. SQLDeveloper
1. 개발 네트워크의 개발 DB에 추가되어 있는 DB Role입니다.
2. 개발 DB에 대해 db_owner 역할에 속하지만, 테이블과 뷰를 생성할 권한은 없습니다.
3. SQL개발을 담당하는 사람이 이 Role에 속합니다.
   
   
3. Developer
1. 개발, 테스트 & QA 네크워크의 DB에 추가되어 있는 DB Role입니다.
2. db_datareader와 db_datawriter 역할에 속합니다.
3. 모든 SP, UDF, Trigger에 대한 View definition 권한을 가집니다.
4. 모든 SP에 대한 Execute 권한을 가집니다.
5. SPExecutor라는 User로 Impersonate (= 가장) 할 권한을 가집니다.
6. SQL 서버와 연동하는 프로그램을 작성하는 개발자가 이 Role에 속합니다.
   
   
4. AppServer
1. 개발, 테스트 & QA, 프로덕트 네트워크의 DB에 추가되어 있는 DB Role입니다.
2. 모든 SP, UDF, Trigger에 대한 View definition 권한을 가집니다.
3. 모든 SP에 대한 Execute 권한을 가집니다.
4. SPExecutor라는 User로 Impersonate (= 가장) 할 권한을 가집니다.
5. SQL 서버에 접속하는 프로그램이 사용할 계정이 이 Role에 속합니다.
   
   
   
   
   

SQLSafe.dbo.DBAs 테이블에 등록되지 않은 사용자가... 테이블이나 뷰에 대한 DDL문을 실행하면, 그 DDL문은 바로 롤백됩니다.

아래 링크를 참고하세요~
2009/07/20 - [SQL Server 팁] - SQL Server 로그인 및 사용자 권한 정책




II. 모델 수정 작업은 DDL 스크립트 실행을 통해서만 가능합니다.

테이블 디자이너를 사용하여 모델을 수정할 수 없습니다.

만약 테이블 디자이너를 통해 테이블 변경이나 생성 작업을 한다면, 아래와 같은 에러 메세지가 출력됩니다.




이런 제약을 둔 가장 큰 이유는... DDL 트리거가 sp_rename을 캐치하지 못하기 때문입니다.

아시다시피 테이블 디자이너를 통해 테이블을 수정할 때 sp_rename이 종종 실행되는데... 이렇게 되면 테이블의 버전을 관리하지 못하게 되기 때문에 부득이 이런 제약을 넣었습니다.

따라서, 실행이 차단되어 있진 않지만 sp_rename을 직접 사용하는 일이 있어서는 안됩니다.



III. NOT NULL 속성의 컬럼을 추가하는 경우, 반드시 DEFAULT 제약 조건 사용

개발 DB에서는 테이블이 비어 있어서 NOT NULL 필드를 추가할 수 있었다해도... 배포하는 과정에서는 상황이 달라질 수 있기 때문입니다.



p.s
문서화와 발판 코드 출력에 사용되기 때문에, 확장 속성으로 테이블과 컬럼의 정의를 잘 관리해 주시기 바랍니다.