데이터베이스 제약 조건은 어떻게됩니까?

RDBMS에 대한 데이터베이스 모델을 검토 할 때 일반적으로 제약 조건 (PK / FK 제외)이 거의 없거나 전혀없는 것이 놀랍습니다. 예를 들어, 백분율은 종종 유형의 열에 저장되며 int( tinyint보다 적절할 수 있음) CHECK값을 0..100 범위로 제한 할 제약 이 없습니다 . SE.SE와 마찬가지로 검사 제한 조건을 제안하는 응답은 종종 데이터베이스가 제한 조건에 대한 잘못된 위치임을 제안하는 주석 을 받습니다 .

제약 조건을 이행하지 않기로 한 결정에 대해 질문 할 때 팀 구성원은 다음과 같이 응답합니다.

• 그들은 그러한 기능이 선호하는 데이터베이스에 존재한다는 것을 알지 못합니다. ORM을 사용하는 프로그래머는 이해할 수 있지만 주어진 RDBMS에 대해 5 년 이상 경험이 있다고 주장하는 DBA는 훨씬 적습니다.

• 또는 응용 프로그램 수준에서 이러한 제약 조건을 적용하고 데이터베이스에서 이러한 규칙을 복제하는 것은 SSOT를 위반하는 좋은 생각이 아닙니다.

최근에는 외래 키를 사용하지 않는 점점 더 많은 프로젝트가 있습니다. 마찬가지로, 여기 SE.SE에 대한 몇 가지 코멘트를 본 적이 보여 사용자가 응용 프로그램 핸들을시키는, 참조 무결성에 대해 많은 관심을하지 않는 것이 있습니다.

팀에게 FK를 사용하지 않도록 선택할 때 다음과 같이 말합니다.

• 예를 들어 다른 테이블에서 참조되는 요소를 제거해야 할 때 PITA입니다.

• NoSQL은 흔들리고 외래 키는 없습니다. 따라서 RDBMS에서는 필요하지 않습니다.

• 성능 측면에서 큰 문제는 아닙니다 (컨텍스트는 일반적으로 작은 데이터 세트에서 작동하는 작은 인트라넷 웹 응용 프로그램이므로 실제로 색인조차 중요하지 않습니다. 주어진 쿼리의 성능이 1.5 초에서 지나친다면 아무도 신경 쓰지 않습니다) ~ 20ms)

응용 프로그램 자체를 보면 체계적으로 두 가지 패턴이 있습니다.

• 응용 프로그램은 데이터베이스로 보내기 전에 데이터를 올바르게 삭제하고 확인합니다. 예를 들어, 102응용 프로그램을 통해 값 을 백분율로 저장하는 방법이 없습니다 .

• 응용 프로그램은 데이터베이스에서 오는 모든 데이터가 완벽하게 유효하다고 가정합니다. 즉, 102백분율로 나오면 어딘가에서 충돌이 발생하거나 사용자에게 그대로 표시되어 이상한 상황이 발생합니다.

• 쿼리의 99 % 이상이 단일 응용 프로그램에서 수행되지만 시간이 지남에 따라 스크립트가 표시되기 시작합니다 (필요할 때 수동으로 실행 된 스크립트 또는 크론 작업). 일부 데이터 작업은 데이터베이스 자체에서 직접 수행됩니다. 스크립트와 수동 SQL 쿼리 모두 유효하지 않은 값을 도입 할 위험이 높습니다.

그리고 여기 내 질문이 온다 :

검사 제한 조건이없고 결과적으로 외래 키가없는 관계형 데이터베이스를 모델링하는 이유는 무엇입니까?

그 가치가 무엇인지,이 질문과 내가받은 답변 (특히 Thomas Kilian과의 흥미로운 토론) 을 통해 데이터베이스 제약 조건에 관한 결론을 내리는 기사 를 작성 했습니다 .

데이터베이스의 서로 다른 사용 사례를 구별하는 것이 중요합니다.

기존의 비즈니스 데이터베이스는 여러 독립적 인 응용 프로그램 및 서비스에 의해 그리고 아마도 인증 된 사용자가 직접 액세스 할 수 있습니다. 데이터베이스 수준에서 잘 고려 된 스키마와 제약 조건을 갖는 것이 중요하므로 단일 응용 프로그램의 버그 나 감독으로 인해 데이터베이스가 손상되지 않습니다. 데이터베이스가 업무상 중요하므로 데이터가 일치하지 않거나 손상되면 비즈니스에 치명적인 결과를 초래할 수 있습니다. 응용 프로그램이 오가는 동안 데이터는 영원히 유지됩니다. 데이터베이스의 일관성과 상태를 보장하기 위해 전용 DBA가있는 장소입니다.

그러나 데이터베이스가 단일 응용 프로그램과 긴밀하게 통합 된 시스템도 있습니다. 단일 임베디드 데이터베이스가있는 독립형 애플리케이션 또는 웹 애플리케이션. 단일 응용 프로그램에서 데이터베이스에 독점적으로 액세스하는 한 응용 프로그램이 올바르게 작동하는 한 제약 조건을 중복으로 고려할 수 있습니다. 이러한 시스템은 종종 프로그래머가 응용 프로그램 코드에 중점을두고 개발하며 관계형 모델에 대한 깊은 이해가되지 않습니다. 응용 프로그램이 ORM을 사용하는 경우 제한 조건은 응용 프로그램 프로그래머에게 친숙한 형식으로 ORM 레벨에서 선언 될 수 있습니다. 로우 엔드에서 우리는 PHP 응용 프로그램은 MySQL을 사용하고, 그렇게 오랜 시간 동안 MySQL은, 전혀 기본적인 제약 조건을 지원하지 않았다가 있었다 일관성을 보장하기 위해 응용 프로그램 계층에 의존.

서로 다른 배경을 가진 개발자가 만나면 문화가 충돌합니다.

이 믹스에는 새로운 분산 형 "클라우드 스토리지"데이터베이스가 있습니다. 성능 이점을 잃지 않고 분산 데이터베이스 일관성을 유지하는 것은 매우 어렵 기 때문에 이러한 데이터베이스는 종종 데이터베이스 수준에서 일관성 검사를 피하고 기본적으로 프로그래머가 응용 프로그램 수준에서 데이터베이스를 처리 할 수 ​​있도록합니다. 응용 프로그램마다 일관성 요구 사항이 다르며 Google 검색 엔진이 서버 전체의 일관성보다 가용성을 우선시하지만 급여 시스템이 많은 제약 조건이있는 관계형 데이터베이스에서 실행되도록 기꺼이합니다.

오늘날 점점 더 많은 시스템이 분산 환경, 클라우드에서 실행되고 "스케일 업"대신 "스케일 아웃"기술을 채택하고 있습니다. 전자 상거래 앱과 같은 온라인 인터넷 애플리케이션을 다루는 경우 더욱 중요합니다.

즉, 확장해야하는 모든 응용 프로그램은 CAP 정리에 의해 제약을 받으며 , 여기서 일관성, 가용성 및 파티션 허용 오차 (네트워크 내결함성) 중 2 개를 선택해야합니다.

CAP 정리를 살펴보면 선택의 여지가 많지 않지만 가용성을 100 % 잃을 수는 없습니다. 네트워크를 100 % 신뢰할 수는 없기 때문입니다.

일반적으로 여러 응용 프로그램이 적당한 시간 동안 일관성이 없지만 사용자가 사용할 수는 없습니다. 예를 들어 Facebook 또는 Twitter에서 약간 순서가없는 타임 라인은 타임 라인에 전혀 액세스하지 않는 것보다 낫습니다.

따라서 관계형 데이터베이스는 일관성은 있지만 가용성은 떨어지기 때문에 여러 응용 프로그램에서 관계형 데이터베이스 제약 조건을 적용하려고합니다.

개인 참고 사항 : 나는 구식이었으며 데이터 일관성이 대부분의 경우 최고 수준의 요구 사항이며 데이터베이스 제약 조건을 좋아하는 오래된 금융 시스템과 협력하고 있습니다. 데이터베이스 제약 조건은 수년에 걸친 나쁜 개발과 개발자 팀에 대한 최후의 방어선입니다.

"수수께끼의 예상 모드". 일관성이 최우선 요구 사항 인 DB "낮은 수준"일관성을 계속 사용합시다. 그러나 때때로, 그것을 내버려 두는 것은 결국 큰 죄가 아닙니다.

-- 편집하다: --

질문에 약간의 편집이 있기 때문에 데이터베이스 IMO에서 제약 조건을 삭제 해야하는 또 다른 합당한 이유가 있습니다. 다중 데이터베이스 기술을 지원하도록 시스템을 설계하는 제품을 처음부터 새로 디자인하는 경우 지원되는 데이터베이스 중에서 최소 공통 분모를 정하고 결국 모든 제어 논리를 그대로두고 제약 조건을 전혀 사용하지 않을 수 있습니다. 너의 어플리케이션.

합법적이지만 나에게도 회색 영역입니다. 원래 질문에서 제안 된 것과 같은 간단한 제약 조건을 지원하지 않는 데이터베이스 엔진을 오늘 찾을 수 없기 때문입니다.

검사 제한 조건이없고 결과적으로 외래 키가없는 관계형 데이터베이스를 모델링하는 이유는 무엇입니까?

먼저 여기서는 SQL이없는 데이터베이스가 아니라 RDBM에 대해서만 이야기하고 있음을 분명히하겠습니다.

FK 또는 PK가없는 몇 가지 데이터베이스를 보았습니다. 제약 조건을 확인하는 것은 아니지만 솔직히 소수입니다. 아마도 나는 큰 회사에서 일하기 때문일 것입니다.

몇 년 동안의 경험에서 나는 몇 가지 이유가 있다고 말할 수 있습니다.

• 초보자 나 취미 프로그래머 의 경우 모델링 기술이 부족
• 데이터베이스 세계와 실질적인 접촉없이 ORM 을 광범위하게 또는 거의 독점적으로 사용
• 팀 또는 소규모 프로젝트에 DBA 또는 기타 데이터 모델링 전문가가 없음
• 개발의 첫 단계에서 DBA 또는 데이터 모델링 전문가 의 참여 부족
• 특정 열 1,2 or 3이 값으로 만 가질 수 있거나 "연령"열 >= 0이 "데이터베이스에 비즈니스 로직을 가지고 있어야" 한다는 것을 강제하는 검사 제한 조건을 고려하는 개발자 커뮤니티의 일부에 의한 의도적 인 설계 결정 . 이 절의 최근 몇 가지 질문과 답변에서 볼 수 있듯이 기본 절조차도 데이터베이스에 속하지 않는 비즈니스 로직으로 간주됩니다. 그렇게 고려하는이 ​​개발자는 가능한 한 적은 제약을 사용하고 참조 코드의 무결성 및 / 또는 단일성까지 모든 코드를 수행 할 것입니다. 나는 이것이 극단적 인 입장이라고 생각한다.
• RDBMS를 키-값 저장소 로 사용하여 RDBMS 테이블을 사용하여 충족하기에 충분히 간단한 요구 사항으로 인해 SQL이없는 동작을 에뮬레이트하기 위해 키-값 스토리지로 RDBM을 사용합니다.
• 데이터베이스가 항상 "앱"에 의해 작성되고 아무도 대량의 데이터로드를 수행하거나 SQL 클라이언트를 통해 행을 편집하거나 삽입 할 필요가 없다고 가정합니다 (많은 경우 앱이 삽입 한 잘못된 데이터를 수정). 최선의 경우 시나리오에는 항상 데이터베이스에 DML 명령을 발행하는 다른 앱 ( "앱"외에)이 있습니다 (SQL 클라이언트).
• 데이터 가 앱이 아닌 비즈니스 소유자에게 속한다는 것을 인식 하지 못합니다.

즉, RDBMS는 거대 기업의 어깨 너머에 구축되었으며 많은 비즈니스 요구 사항에 매우 효율적으로 입증되어 일련의 참조 무결성을 강화하는 일상적인 작업을 수행하는 프로그래머를 해방시키는 매우 고급 소프트웨어라고 진술하고 싶습니다. 이진 파일 또는 텍스트 파일. 내가 항상 말했듯이 "우리는 더 이상 하나의 앱 하나의 데이터베이스 세계에 살고 있지 않습니다" . 최소한 SQL 클라이언트는 "앱"외에 DML을 발급합니다. 따라서 데이터베이스는 사람이나 프로그래밍 오류로부터 합리적인 수준으로 스스로를 방어해야합니다.

RDBMS가 제대로 확장되지 않는 잘 알려진 요구 사항 유형에서는 SQL이 아닌 기술을 채택해야합니다 . 그러나 수천 줄의 코드 (생성 또는 유형)가 RDBMS가보다 효율적인 방법으로 시행해야하는 사항을 시행하는 데 제약이없는 관계형 데이터베이스의 확산이 걱정되고 있습니다.

기술 결정을 내리는 외부 제약이 있습니다. 데이터베이스 필드 제약 조건을 정기적으로 사용해야 할 필요가 있거나 사치스러운 상황은 거의 없습니다.

1. 기업에는 DBA와 함께 앱과 데이터베이스를위한 개발자가 있지만 대부분의 개발자는 이러한 유형의 환경에서 작업하지 않습니다. 코드에서 할 수있는 한 많이합니다. 또한 데이터베이스 측의 일부는 비즈니스 규칙에 관여하지 않습니다. 그들은 주로 일을 계속하기 위해 존재합니다. 그들은 db에서 제약을 강요하지 않을 것입니다. 레거시 앱, 통합, 마이그레이션, 합병, 인수를 처리해야하는 경우 db 제약 조건이 최상의 솔루션 일 수 있습니다.
2. db를 오버로드하면 병목 현상이 발생하여 문제에 더 많은 머신을 던져서 쉽게 해결할 수 없습니다. DB 언어가 주요 성능 저하없이 일부 프로그래밍 문제를 처리하지 못하는 상황이 있으므로 모든 것에 제약 조건을 사용할 계획이 없습니다. 문제에 대해 2를 던지는 것은 어려운 일이므로 Stackoverflow에는 하나의 데이터베이스 서버가 있습니다.
3. 자동화 된 테스트-그들은 거기에 도착하지만 많은 DB 개발자들이 IDE / 테스트 프레임 워크와 함께 파티에 늦었습니다.
4. 배포-더 많은 db 항목은 더 복잡합니다. 제약 조건을 위반하는 데이터가 있기 때문에 클라이언트 데이터베이스에 대한 업데이트가 허용되지 않으면 어떻게됩니까? 이 문제를 해결할 방법이 없다면 게임 오버. 앱에서 사용자가 필요에 따라이를 처리하도록하거나 일부 관리자에게 일괄 처리하도록 지시 할 수 있습니다.
5. app / api / service만이 데이터베이스에 데이터를 쓸 것이므로 왜 귀찮게합니까? 이것은 대부분의 시간을 유지하기 때문에 일반적이지 않습니다.
6. DB 오류를 처리하는 것은 수없이 많은 제약 조건 위반이 없으면 모든 것이 실패 할 경우에 대처할 수 없을 정도로 어렵습니다.

많은 개발 팀은 DB 개발자에게 너무 많은 제어권을주고 싶지 않습니다. 둘 이상을 얻는다면 운이 좋으므로 휴가는 많은 재미입니다. 데이터베이스 도메인에 대한 절대적인 제어가 필요한 사람은 많지 않으며 모든 쿼리, 비즈니스 규칙, 성능, 가용성, 보안 및 어떤 데이터가 어떤 RAID로 전달되는지를 책임집니다. 실행할 수있는 저장 프로시 저는 다음과 같습니다. 즐기세요 테이블을 만지는 것에 대해 생각조차하지 마십시오.

이것은 내 경력 (거의 40 년)과 DBMS를 작성할 때 어려움을 겪고있는 문제입니다. 내 엔드 포인트에 대한 설명은 여기 ( http://unibase.zenucom.com) 입니다. 여기 내 생각이 있습니다.

1. 일반적으로 대부분의 제약 조건은 응용 프로그램에서 더 잘 처리되므로 응용 프로그램의 다른 부분에서 다른 제약 조건을 적용 할 수 있습니다. 예를 들어, 주 코드는 모든 관할 지역에 적용되지 않을 수 있습니다.
2. 옆으로 %를 조심하십시오. 마크 업이 100 % 이상이거나 파산합니다. :)
3. 제약 조건은 부정적으로 설명하는 것이 가장 좋습니다. 즉 그들이 될 수없는 것, 그렇지 않아야하는 것. 항상 간단한 목록입니다.
4. 외래 키는 항상 좋으므로 사용해야합니다. 풀 스톱. FK는 RDBMS에서 몇 가지 시맨틱 구성 중 하나이며 매우 유용합니다. 가장 큰 어려움은 FK가 제거 될 때 값이 매달려 있는지 또는 FK 레코드를 삭제하지 않는 이유로 종속 행을 사용할지 여부를 결정하는 것입니다.
5. 실제 세계의 제약 조건은 일반적으로 단일 필드 값 제한보다 더 복잡합니다.
6. 응용 프로그램 수준에서도 일부 제약 조건은 제대로 작동하지 않습니다. 예를 들어 공격적인 날짜 확인은 명백히 좋은 날짜의 오류를 숨 깁니다. 현명하게 보이는 날짜에 오류를 측정하려면 연산자 오류가 필요합니다.

데이터베이스 제약 조건은 현명한 아이디어 일 수 있지만 실제로 사용하는 것은 어떻습니까? 백분율 제한을 사용하십시오. 이를 적용하면 DB는 유효하지 않은 백분율을 기꺼이 거부합니다. 그리고? 예외를 처리하려면 비즈니스 로직이 필요합니다. 이는 실제로 잘못된 비율을 작성하는 비즈니스 로직이 다른 곳에서 이미 실패했음을 의미합니다. 요약하자면 PK / FK와 같은 실제 제약 조건 만 남게됩니다.

요즘 사람들은 소프트웨어 (예 : Entity Framework)를 사용하여 테이블과 열을 자동으로 생성합니다. 아이디어는 SQL 기술이 필요하지 않아서 뇌 용량을 늘리는 것입니다.

소프트웨어가 "제대로 작동"할 것이라는 기대는 종종 비현실적이며, 인간이 원하는 제약을 만들지 않습니다.

최상의 결과를 얻으려면 SQL을 사용하여 테이블을 작성하고 제한 조건을 수동으로 추가하십시오. 그러나 때때로 사람들은이를 수행 할 수 없습니다.