참조 무결성은 언제 적절하지 않습니까?

Question

입력시 특정 값을 제한하거나 삭제 요청시 삭제되지 않도록하기 위해 참조 무결성을 가질 필요가 있음을 알고 있습니다. 그러나이 메커니즘을 항상 사용하지 못하도록하는 유효한 유스 케이스에 대해서는 분명하지 않습니다.

나는이 여러 개의 하위 질문에 빠질 것 같아요

1. 때 참조 무결성이 적절하지 않다?
2. 외래 키 목록의 다중 및/또는 불완전한 하위 집합을 포함하는 필드를 갖는 것이 적절합니까?
3. 일반적으로 이것은 스키마 구조 디자인 결정 또는 인터페이스 디자인 결정이어야합니까? (또는 둘 중 하나 또는 둘 모두)

생각들?

Answer 1

참조 무결성은 언제 적절하지 않습니까?

일반적으로 데이터가 트랜잭션 데이터베이스의 읽기 전용 복사본 인 데이터웨어 하우스에 사용되지 않는 경우 참조 상호 참조. RI가 필요하지 않은 또 다른 예는 행 ID를 포함하는 정보를 기록하려는 경우입니다. 읽기 전용 로그 테이블에 대한 참조 무결성을 유지하는 것은 데이터베이스 오버 헤드의 낭비입니다.

외래 키 목록의 복수 및/또는 불완전한 하위 집합을 포함하는 필드를 사용하는 것이 적절합니까?

때때로 데이터 품질보다 데이터를 캡처하는 것이 더 중요합니다. 각자 독자적으로 데이터 품질 문제로 고통받는 서로 다른 시스템의 많은 양의 데이터를 집계한다고 가정 해보십시오. 때로는 데이터 품질이 좋아졌고 깨진 키 등이 있어도 한 곳에서 모든 것을 처리하는 것이 진정한 데이터 품질로 옮겨가는 출발점이됩니다. 이상적은 아니지만, 타협이 트레이드 오프를 능가 할 수 있기 때문에 발생합니다.

일반적으로 스키마 구조 디자인 결정 또는 인터페이스 디자인 결정이어야합니까? (또는 둘 중 하나 또는 모두)

시스템 개발에 관한 모든 것이 정보 보안에 중점을두고 있으며 그 핵심 요소는 데이터 무결성입니다. 데이터베이스 구조는 가능할 때 이러한 것들을 강제하는쪽으로 기울어 져야하지만, 종종 현대 데이터베이스 시스템을 다루지 않습니다. 때로는 데이터 소스가 오래된 골동품 응용 프로그램을 사용하는 구식 AS400 일 수도 있습니다. 때로는 데이터 무결성을 제공하는 데이터 및 비즈니스 계층을 구축해야합니다.

그냥 내 생각.

Answer 2

1. 아니요, NoSQL의 소수의 사람들, 다 값 및 oo-db 영역이 다르게 느껴지 겠지만. 그 (것)들을 경청하지 말라, 틀리다.
2. 예. 예를 들어, 차량이 (로이드, 빈)으로 고유하게 식별되면 로트는 로트 테이블에 대한 외래 키입니다. 많은 사진을 찾으려면 vehicle_pictures 키의 하위 집합 (lotid, vin)의 lotid)을 사용하여 lot_ table 바로 오른쪽에있는 lot_pictures 테이블에 참여할 수 있습니다. 아니면 내가 너를 이해하지 못하니?
3. 스키마, 인터페이스가 두 번째로옵니다. 스키마가 좋지 않은 경우 좋은 인터페이스를 갖는 것이 장기 목표는 아닙니다.

Answer 3

내가 들어 본 유일한 사례는 방대한 양의 데이터를 데이터베이스에로드하려는 경우입니다. 이 경우 데이터가 유효하다는 것을 확실히 알고있는 한 참조 무결성을 해제하는 것이 좋습니다. 로드/마이그레이션이 완료되면 참조 무결성을 다시 켜야합니다.

프로그래밍 코드와 데이터베이스에 데이터 유효성 검사 규칙을 적용하는 방법에 대한 논쟁이 있습니다. 소프트웨어의 사용 사례에 따라 달라집니다. 단일 응용 프로그램 만 데이터베이스의 유일한 경로라면 프로그램 자체에 유효성 검사를 넣을 수 있으며 아마도 괜찮을 것입니다. 그러나 여러 프로그램이 데이터베이스 (예 : 응용 프로그램 및 친구의 응용 프로그램)를 동시에 사용하는 경우 데이터가 항상 유효하도록 데이터베이스에 비즈니스 규칙을 원할 것입니다.

'유효성 검사 규칙'을 통해 'cart in items> 0'과 같은 규칙에 대해 이야기하고 있습니다. 유효성 검사 규칙을 원하거나 원하지 않을 수도 있습니다. 하지만 기본/외래 키가 항상 중요하다고 생각합니다. 나중에 키를 가질 수도 있습니다. 나는 당신이 어떤 시점에서 복제를 원한다면 그것들이 필요하다고 생각한다.

Answer 4

참조 무결성은 성능, 확장 성 및/또는 다른 기능을 희생시키지 않으면 항상 적절할 것입니다.

일부 응용 프로그램에서는 참조 무결성이 데이터 품질보다 중요한 것으로 트레이드 될 수 있습니다.

Answer 5

1. 참조 무결성은 언제 적절하지 않습니까?

   때로는 대량으로 많은 레코드를 복사 또는 백업의 어떤 종류에서 데이터를 복원 할 때, 일시적 를 참조 무결성의 제약을 해제하는 것이 편리 입니다.

2. 외래 키 목록의 복수 및/또는 불완전한 하위 집합을 포함하는 필드를 사용하는 것이 적절합니까?

   이런 식으로 데이터를 복제하면 이 정규화라는 개념에 반해됩니다. 이 접근에는 장단점이 있습니다.

3. 일반적으로 스키마 구조 디자인 결정 또는 인터페이스 디자인 결정이어야합니까? (또는 둘 중 하나 또는 모두)

   나는 스키마 디자인 결정이라고 생각합니다. 관계형에서 문제를 모델링하는 가장 좋은 방법은 입니다. 용어. 의 의도대로 데이터베이스를 사용하십시오.