다중 서버 RDBMS 또는 애플리케이션이 데이터베이스 참조 무결성을 처리해야합니까?

데이터베이스 관리 시스템 (이 경우 MS SQL 2005) 또는 응용 프로그램에서 외래 키, 제약 조건, 기본값 등과 같은 항목을 처리해야합니까? 나는 양쪽의 의견을 듣고 솔직히 어떤 길을 갈지 확신하지 못한다.

여러 서버 / 데이터베이스에 걸쳐있을 가능성이 있으며 연결된 서버에서 외래 키를 사용할 수 있다고 생각하지 않습니다. 그 외에도 데이터베이스 디자인에는 순환 참조가있어 ON UPDATE CASCADE모든 것을 사용할 수 없습니다.

데이터베이스는 MS SQL 2005 (아마도 2008)이며 데이터베이스와의 모든 상호 작용은 응용 프로그램을 거쳐야합니다.

DB가 애플리케이션 외부에서 수정 될 가능성이있는 경우 데이터베이스에 제약 조건이 필요합니다. DB가 항상 응용 프로그램의 백엔드에 지나지 않을 경우, 만일을 대비하여 문서화하고 성능 저하가 그다지 나쁘지 않은 경우 그대로 유지하더라도 DB를 그대로 둘 수 있습니다. (Peoplesoft 소프트웨어는 이러한 방식으로 작동합니다. 제약 조건은 소프트웨어에 있으며, Oracle에서 SYS로 모든 것을 실행합니다.)

응용 프로그램에서 이와 같은 것을 모니터링하기를 원하므로 지능적으로 반응하고 데이터베이스 오류 메시지를 사용자에게 되돌려주는 것이 아닙니다.

그렇습니다. 이것은 이중 범위이지만, 그렇지 않으면 예방 가능한 데이터 손상이나 나쁜 사용자 인터페이스를 얻을 수 있습니다.

둘 다 이상적입니다. DB가 처리 하지 않아야 하지만 응용 프로그램이 DB에서 거부 할 데이터를 제공하면 런타임 오류이므로 앱에는 참조 무결성을 유지하기위한 코드가 적어도 있어야합니다. 또한 DB에서 SQL에 올바른 제약 조건을 설정하는 것이 클라이언트 쪽 코드를 설정하는 것보다 훨씬 간단하므로 DB에서이를 수행하면 필요한 작업량이 크게 줄어 듭니다.

중요한 경우 데이터베이스가 처리하도록하십시오. 이렇게하면 누군가 애플리케이션 외부의 데이터베이스에 액세스하고 일관되지 않거나 중복 된 데이터를 변경하거나 입력하는 것에 대해 걱정할 필요가 없습니다. "ZZZ의 액세스 등급을 가진 부서 X의 사용자 만 그룹 999에 속해야합니다"와 같은 일부 고급 응용 프로그램 관련 내용이 아니라면 일반적으로 "참조"무결성이라고하는 것은 아닙니다.

나는 데이터베이스에 넣었다고 말할 것이다. 영구 프레임 워크를 사용하는 경우 키를 자동으로 선택합니다.

둘 다 확실히 갈 길입니다. 잘못된 업데이트 및 삽입을 방지하고 사용자에게 잘못된 내용과 해결 방법을 알려주는 코드의 유효성 검사 논리가 필요합니다. 그리고 데이터베이스에 백엔드를 중지 시켜서 무언가가 들어와 유효성 검사를 거치지 않으면 문제를 해결하지 않는 것이 좋습니다.

데이터베이스를 더 높은 수준으로 유지해야합니다. EG, 참조 적법성 및 아마도 null이 아닌 것을 강제하십시오. 그러나 길이나 형식을 제한하는 것에 대해 걱정하지 마십시오.