제약조건은 데이터베이스에 어떤 이점을 제공합니까?

StackOverflow https://stackoverflow.com/questions/1269545

  •  13-09-2019
  •  | 
  •  

문제

나는 이 질문이 약간 "친환경"적인 측면에서 보일 수 있다는 것을 알고 있지만, 내가 접한 수많은 "기업" 또는 "상업용" 데이터베이스 이후에 나는 이 질문을 하기 시작했습니다.제약조건이 데이터베이스에 제공하는 이점은 무엇입니까?고유 제약 조건보다는 외래 키 제약 조건에 대해 더 많이 묻고 있습니다.성능 향상을 제공합니까, 아니면 데이터 무결성만을 제공합니까?

나는 외래 키가 없거나 지정된 기본 키가 없는 관계형 데이터베이스의 수에 다소 놀랐습니다(필드에 대한 제약 조건이 null이 아니거나 필드에 대한 고유 제약 조건일 뿐임).

생각?

도움이 되었습니까?

해결책

"그냥"데이터 무결성? 당신은 그것이 사소한 일이라고 말합니다. 모든 응용 분야에서 중요합니다. 그렇습니다. 그것은 그것을 제공하며, 그것은 큰 이점입니다.

다른 팁

데이터 무결성은 그들이 제공하는 것입니다. 성능 비용이 있다면 (적어도 아주 작은).

그들은 성능과 데이터 무결성을 모두 제공하며 후자는 모든 심각한 시스템에 가장 중요합니다. 나는 외래 키가없는 데이터베이스를 볼 때마다, 그리고 트리거를 통해 모든 무결성이 이루어지는 곳 (전혀). 그리고 나는 거기에서 꽤 많은 사람들을 보았습니다.

다음은 처음에 제약 조건을 얻는다고 가정합니다.

  • 귀하의 데이터는 제약과 관련하여 유효합니다.
  • 데이터베이스는 귀하의 데이터가 제약 조건과 관련하여 유효하다는 것을 알고 있으며 데이터베이스를 쿼리하거나 업데이트 할 때이를 사용할 수 있습니다 (예 :보기에서 쿼리에 대한 불필요한 조인을 제거).
  • 제약 조건은 미래의 데이터베이스 사용자를 위해 문서화되어 있습니다.
  • 제약 조건 위반은 가능한 빨리 잡힐 것입니다. 나중에 실패하는 일부 관련이없는 프로세스가 아닙니다

관계 이론에서, 일관성이없는 데이터를 허용하는 데이터베이스는 실제로 관계형 데이터베이스가 아닙니다. 데이터베이스를 "관계형"으로 유지하려면 데이터 무결성과 일관성을 위해서는 외국 키가 필요합니다. 즉, 데이터베이스의 논리적 모델은 항상 정확합니다.

실제적인 관점에서, 일반적으로 외국 키를 정의하고 DB 엔진이 관계가 유효한지 확인하는 것이 더 쉽습니다. 다른 옵션은 다음과 같습니다.

  • 아무것도 - 어느 시점에서 데이터 손상을 보장합니다
  • DB 트리거 - 일반적으로 느리고 성능이 떨어집니다.
  • 응용 프로그램 코드 - 올바른 코드를 호출하는 것을 잊거나 다른 응용 프로그램이 데이터베이스에 액세스하는 것을 잊어 버릴 때 결국 문제가 발생합니다.

데이터는 자산입니다. 많은 교과서가 말합니다.

그러나 실제로는 잘못되었습니다. 오히려 "정확한 데이터는 자산이며 잘못된 데이터는 책임입니다"라고 말해야합니다.

데이터베이스 제약 조건은 데이터가 정확하다는 최상의 보장을 제공합니다.

일부 DBMS (예 : Oracle) 제약 조건은 실제로 개선하다 Optimiser는 제약 조건을 사용하여 데이터 구조에 대한 지식을 얻을 수 있기 때문에 일부 쿼리의 성능. 몇 가지 예는 참조하십시오 이 Oracle Magazine 기사.

필요한 모든 제약 조건이 데이터베이스에 있어야 한다고 말하고 싶습니다.외래 키 제약 조건은 사용할 수 없는 데이터를 방지합니다.가지고 있으면 좋은 것이 아닙니다. 쓸모 없는 데이터베이스를 원하지 않는 한 필수 사항입니다.외래 키는 삭제 및 업데이트 성능을 저하시킬 수 있지만 괜찮습니다.삭제하는 데 시간이 조금 더 걸리는 것(또는 시스템에 명령이 있으므로 이 사람을 삭제하지 않도록 애플리케이션에 지시하는 것) 또는 사용자를 삭제하고 데이터는 삭제하지 않는 것이 더 낫습니까?외래 키가 부족하면 데이터 쿼리 시 예상치 못한 심각한 문제가 발생할 수 있습니다.예를 들어 비용 보고서는 관련 데이터가 있는 모든 테이블에 의존할 수 있으며 하나 이상의 테이블에 조인할 항목이 없기 때문에 중요한 데이터를 표시하지 못할 수 있습니다.

고유한 제약 조건은 괜찮은 데이터베이스의 요구 사항이기도 합니다.필드 또는 필드 그룹이 고유해야 하는 경우 데이터베이스 수준에서 이를 정의하지 못하면 해결하기 매우 어려운 데이터 문제가 발생합니다.

다른 제약 조건은 언급하지 않았지만 그래야 합니다.테이블의 모든 데이터에 항상 적용되어야 하는 비즈니스 규칙은 항상 데이터 유형(예: '02\31\2009'를 유효한 날짜로 허용하지 않는 데이터 시간 데이터 유형), 제약 조건(예: 필드가 100보다 큰 값을 갖는 것을 허용하지 않는 것) 또는 트리거를 통해 논리가 너무 복잡해서 일반 제약 조건으로 처리할 수 없다는 것입니다.(무엇을 하고 있는지 모르는 경우 트리거를 작성하기가 까다로우므로 이렇게 복잡한 로직이 있으면 팀에 데이터베이스 전문가가 있는 것이 좋습니다.) 순서가 중요합니다.데이터 유형이 첫 번째 선택이고 그 다음에는 제약 조건이 따르고 그 다음에는 트리거가 마지막 선택입니다.

더 간단한 응용 프로그램 코드

그들이 제공하는 한 가지 좋은 점은 응용 프로그램 코드가 오류 확인 및 유효성 검사를 훨씬 적게 수행해야한다는 것입니다. 이 두 가지 코드를 대조하고 수천 개의 운영을 곱하면 큰 승리가 있음을 알 수 있습니다.

get department number for employee  # it's good coz of constraints
do something with department number

vs.

get department number for employee
if department number is empty
    ...
else if department number not in list of good department numbers
    ....
else
    do something with department number

물론, 제약을 무시하는 사람들은 어쨌든 코드 검증에 많은 노력을 기울이지 않을 것입니다 ... :-/

아, 데이터 제약이 변경되면 코드 변경 문제가 아닌 데이터베이스 구성 문제입니다.

무결성 제약조건은 공유 데이터베이스를 사용하여 여러 애플리케이션을 통합할 때 특히 중요합니다.

단일 애플리케이션의 코드에서 데이터 무결성을 적절하게 관리할 수 있지만(그렇지 않더라도 최소한 손상된 데이터는 해당 애플리케이션에만 영향을 미침) 여러 앱을 사용하면 복잡해집니다(적어도 중복됨).

"아, 데이터 제약이 변경되면 코드 변경 문제가 아닌 데이터베이스 구성 문제입니다."

디자인에서 사라지는 제약이 아니라면. 이 경우 제거 된 제약 조건에 따라 일부 코드가 작성되었을 수 있기 때문에 코드 영향이 분명히 있습니다.

선언 된 제약 조건을 "Laxing"또는 "제거"할 때는 항상 고려해야합니다.

그 외에는 물론 완전히 옳습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top