관계형 데이터베이스의 제약 조건-완전히 제거하지 않는 이유는 무엇입니까?

요즘 테이블 (SQL 서버 내부) 사이에 제약 조건을 구축 해야하는 이유가 있습니까? 그렇다면 언제? 내 영역의 대부분의 응용 프로그램은 개체 원칙을 기반으로하며 필요에 따라 테이블이 결합됩니다. 수요는 응용 프로그램의 요구를 기반으로합니다. 간단한 룩업을 위해 여러 개의 제한된 테이블을로드하지 않을 것이며 (조치 후) 다른 간단한 룩업이 필요합니다.

EntityContext, Linq2Data, NHibernate와 같은 ORM 도구는 또한 제약 조건을 자체적으로 처리하며, 적어도 서로에게 필요한 테이블을 알고 있습니다. 서버 내에서 제약 조건을 수행하는 것은 동일한 변경 사항을 두 번 (강제) 만드는 것입니까?

이것은 일반적으로 결정에 대한 질문이 아니지만이 데이터베이스는 상당히 다르게 설계되었습니다. 디자인은 규칙적으로 좋아 보이며 대부분 응용 프로그램에서 사용하는 객체를 반영합니다. 나를 방해하는 것은 "캐스케이드가 아닌"SQL Server 내부에 구성된 모든 제약 조건입니다. 즉, 새 데이터베이스 쿼리를 코딩 할 때 "검색 및 찾기"를 수행해야합니다. 일부 경우 단일 삭제를 위해 최대 10 단계의 정확한 순서가 필요합니다.

이것은 나를 놀라게하고 그것을 처리하는 방법을 모르겠습니다.

저의 단순한 세계에서, 그 설정은 제약이 대부분의 목적을 잃게 만듭니다. 설계에 대한 지식없이 호스트에서 데이터베이스에 액세스 한 경우에는 OK입니다.

이 시나리오에서 어떻게 행동 하시겠습니까?
db에서 모든 제약 조건을 제거하고 응용 프로그램 수준에서 유지하는 이유는 무엇입니까?

DB에서 제약을 제거하지 않는 두 가지 일반적인 이유 :

• ORM을 사용하거나 사용하지 않을 수 있는 더 많은 앱이 현재 또는 미래에 액세스 할 수 있습니다 . 이러한 앱 개발자가 모든 제약 조건을 충실하게 복제하더라도 (낮은 수준의 비 ORM 솔루션을 사용하는 것이 훨씬 어려울 수 있음) 항상 추가 작업입니다. 그리고 그렇지 않다면, 하나의 작은 생략만으로도 스키마 무결성을 깨뜨리기에 충분합니다 . 대부분의 회사에서 DB에 저장된 데이터는 비즈니스의 생명력이므로 모든 수단을 통해 무결성을 보장해야합니다. 그리고 이것을 달성하기 위해 노력하고 입증 된 가장 좋은 방법은 DB에 최대한 많은 제약 조건을 구현하는 것입니다.
• 쿼리 최적화 프로그램은 DB 수준에 알려진 제약 조건에 크게 의존합니다. 제약 조건을 제거하면 쿼리 성능이 저하 될 수 있습니다 . 당신은 즉시 그것을 알아 차리지 못할 수도 있지만 언젠가는 당신을 때리게 될 것이고, 그때까지 쉽게 고치기에는 너무 늦을 수도 있습니다. 사물의 본질은 정확한 성능 측정과 근본 원인을 정확히 파악하기위한 세부 분석을 통해 신중하고 신중하게 설계를 개선 할 가능성이 가장 적을 때 최대로드 시간에 DB 성능이 저하되는 경향이 있다는 것입니다.

DB 스키마와 같은 구체적인 사례는 원래 ORM 도구에 의해 생성되었거나 관계형 환경에 대해 잘 모르는 사람이 설계 한 것처럼 들릴 수 있으므로 관계형 관점에서 차선책입니다. ORM보기와 일관성을 유지하면서보다 "자연적인"관계형 디자인으로 분석하고 개선하는 것이 좋습니다. 이 분석에 DB 전문가를 참여시키는 것이 유용 할 수 있습니다.

응용 프로그램은왔다 갔다 할 수 있지만 데이터는 영원히 남아 있습니다. 우리 회사의 DB는 30-40 세 이상이며 회사가 존재하는 한 계속 유지됩니다. 응용 프로그램이 변경되고 개발자가왔다 갔다합니다. 무결성과 논리 데이터 모델이 좋은 것이 좋습니다. 이렇게하면 복잡한 코드베이스를 거치지 않고도 데이터를보고 의미있는 이해를 얻을 수 있습니다. 이것은 또한보고에 크게 도움이됩니다. 또한 응용 프로그램은 버그를 가질 수 있고 가질 수 있으며 DB 제약 조건은 이에 대한 보호입니다. 내 기본 위치는 가능한 한 많은 제약 조건 (FK 및 검사)을 유지하는 것입니다.
제약 조건이없는 유일한 이유는 디자인 패턴 에서 계층 당 테이블 또는 성능 문제를 허용하지 않는 경우 입니다.

나를 방해하는 것은 "캐스케이드가 아닌"SQL Server 내부에 구성된 모든 제약 조건입니다.

그것은 나에게 방해가되지 않습니다. 그것은 누군가가 좋은 의미를 보여 주 었음을 의미합니다. 계단식 삭제는 종종 데이터베이스에 매우 좋지 않습니다. 우선 관련 테이블에 데이터가있는 경우 삭제가 실패하는 경우가 있습니다. 예를 들어, 과거에 주문을 한 고객이있는 경우, 고객이 삭제되기를 원하지 않거나 주문 대상에 대한 데이터를 잃어 버리고 계단식 삭제 woudl이 재무보고를 엉망으로 만드는 레코드를 제거합니다. .

개발자의 편의가 가장 중요하다고 생각하는 것 같습니다. 데이터베이스 세계에서 이것은 사실이 아닙니다. 데이터 무결성은 성능과 데이터 보안이 가장 먼저 따르는 가장 중요한 것입니다. 쿼리를 작성하는 데 시간이 더 걸리면 그렇게하십시오.

데이터베이스는 일반적으로 여러 응용 프로그램, 즉 하나 이상의 웹 사이트 또는 데스크톱 응용 프로그램,보고 응용 프로그램, 웹 서비스, 쿼리 창, ETL 프로세스 등에서 작동합니다. 데이터베이스 수준에서 제약 조건을 적용하지 않으면 먼저 무결성이 손실됩니다 해당 응용 프로그램 중 하나 인 데이터의 일부 규칙이 모든 규칙을 준수하지 않을 수 있습니다. 둘째, 나중에 다른 응용 프로그램을 사용하기로 결정한 경우 이러한 제약 조건을 여러 번 코딩하고 다시 작성해야합니다. 셋째, 응용 프로그램을 통해 발생하지 않는 일종의 데이터 유지 관리 작업을 수행해야하는지 (예를 들어 잘못된 고객 데이터 가져 오기에서 데이터 수정 또는 한 클라이언트에서 10,000,000 레코드 모두 변경) 여부를 미리 제어 할 수 없습니다. 회사가 경쟁 업체에 의해 구매 될 때 다른 고객에게). 일반적으로 응용 프로그램 개발자는

기본적으로 말한 어딘가를 읽었습니다 . 데이터는 응용 프로그램의 핵심입니다 . 만약 당신은 당신의 UI를 통해 오직 액세스 데이터 (그리고 내 말은 지금까지 연리지처럼, 영원히 ... 또는 어쨌든 응용 프로그램의 수명에 대한) 다음 필요하지 않은 데이터베이스 제약. 그러나 웹 서비스, 퍼블릭 API, 레이크 작업 / SQL 작업 / 크론 / 자동화 된 스크립트와 같이 앱 자체 이외의 데이터가 데이터를 만질 필요가있을 가능성이 있습니다. DB 제약 조건을 유지하여 도로.

나는 이것이 당신이 DRY를 적용 해서는 안되는 소프트웨어 개발의 한 영역이라고 굳게 믿는다. (그리고 나는 그 진술에 대한 비보를 충분히 기대하고있다). 데이터는 응용 프로그램의 핵심이자 영혼입니다. 수리를 넘어서 손상된 경우에는 게임 오버입니다. 필요한 모든 곳에서 제약 조건을 적용하는 것이 IMO의 가치가 있습니다. 이것이 DB 수준에 대한 트리거 및 제약 조건, 미들웨어에 대한 서버 측 유효성 검사 및 UI (웹 앱의 경우)에 대한 클라이언트 측 Javascript의 형태를 의미하는 경우 데이터가 항상 깨끗한 상태를 유지하는 것은 IMO가 필요합니다. .

ORM의 의미를 알고 있습니까? 객체 관계형 매핑. 인용 위키피디아 " 호환되지 않는 유형 시스템 간에 데이터를 변환하는 기술 ". 그렇습니다. 관계형 모델과 객체 모델은 서로 맞지 않습니다. ORM은 두 유형 시스템의 규칙을 모두 준수하여 상당히 좋은 변환을 수행합니다. RDBMS는 이러한 방식으로 구성되어 제한 조건을 사용하여 데이터 무결성을 달성합니다. 일반적으로 무결성은 매우 좋은 것이므로 ORM은 객체 데이터를 저장하기 위해 데이터 모델을 만들 때이를 사용하는 경향이 있습니다. ORM에 "비 연쇄"제약 조건을 사용해야 할 충분한 이유가있을 수 있습니다. 그리고 이로 인해 특정 객체를 생성 / 업데이트 / 삭제하는 대신 복잡한 쿼리를 수행해야하는 경우 ORM 설정에 문제가 있습니다.

관계형 개념을 성가신 것으로 생각한다면 왜 객체 데이터베이스를 사용하지 않습니까? 얼마 전 그들은 느리게 (대부분의 사람들이 여전히 RDBMS를 사용하는 이유입니다) 그러나 내가 들었던 것에서 조금 변경되었습니다. 모든 관계형 이쑤시개를 제거합니다. 단순히 물건을 넣고 물건을 꺼내십시오.

이것이 eBay가 한 일이며 아마도 세계에서 가장 큰 데이터베이스 중 하나 일 것입니다.

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

참조 무결성에 의해 성능이 향상되는 것에 대해 위에서 언급 한 내용에도 불구하고 실제로 성능이 저하 될 수 있습니다. 그렇기 때문에 방대한 데이터베이스가 제약 조건을 없애고 응용 프로그램 계층에서 작업을 수행 한 이유입니다. 그리고 내가 알 수있는 한 그것이 유일한 좋은 이유입니다.

이러한 제약 조건을 제거하면 데이터를 깨끗하게 유지하고 자체 문제를 일으키는 안전망을 근본적으로 풀 수 있습니다. 모든 것과 마찬가지로 그것은 균형을 잡는 행위입니다. 일반적으로 참조 무결성을 유지하는 것이 옳은 일이라고 생각합니다.

강력한 참조 무결성을 갖춘 개발 환경에서 일한 결과 개발자의 관점에서 볼 때 이것이 완전히 고통 스러울 수 있다는 것을 알고 있습니다. 종종 개발 환경에서 약간의 더티 데이터는 중요하지 않으며 행을 삭제하는 방법을 연구하는 데 1 시간 이상이 걸릴 수 있습니다. 그러나 제약 조건으로 인해 스키마가 명시 적으로 만들어 지므로 매우 유용 할 수도 있습니다.

첫째-내 대답 : 아니요. 데이터를 돌보기 위해 응용 프로그램에만 의존해서는 안됩니다.

ORM은 종종 "직접적인"DB 상호 작용에 대한 경멸의 문화를 장려하고 종종 정규화 / 참조 무결성을 희생하면서 큰 논쟁을 일으킨다. 테이블은 관계형 모델에 암시적인 디자인을 희생하면서 임의의 객체 계층에 강제로 매핑됩니다. OOP가 선호하는 디커플링은 애플리케이션이 데이터 구조에서 디자인을 느꼈을 때 여기서 희생 될 수있다. ORM은 큰 유용성을 보여 주었지만 SQL의 남용 또는 불신에 근거한 것으로 보입니다.

새로운 패러다임은 (재) 신흥입니다. 개발자 팀이 새로운 프로그래밍 방법론을 채택하기로 결정하면 ORM의 요구 사항에 따라 구조화 된 데이터에 어떤 영향을 미칩니 까?

@Jacek Prucia에 동의합니다. ORM은 RDBMS에 적합하지 않다고 생각합니다. 개인적으로 RDBMS에서 DBAL을 선택하거나 ORM과 함께 OODB를 선택합니다.

제약 조건은 데이터베이스 수준에서 일관성과 데이터 무결성을 보장하는 유일한 방법입니다. 물론 애플리케이션 코드를 사용하여 제약 조건을 적용 할 수 있지만 나중에 데이터를 직접 수정해야하는 경우에는 어떻게됩니까? 데이터 무결성을 유지하는 방법을 이해할 수 있지만 다른 사람은 그렇지 않을 수 있습니다. 데이터 수준에서 제약 조건을 유지하면 누군가가 이해하지 못하는 곳에서 원숭이를 놀아도 무결성이 보장됩니다.

또한 응용 프로그램을 다시 작성해야하지만 동일한 데이터베이스가 있어야한다고 가정 해 봅시다. 코드의 모든 제약 조건은 잘못된 데이터를 허용하면서 일부 항목을 막는 버그를 요구합니다.

개발할 때는 간단하게 유지하십시오. 제약 조건을 사용하면 가능합니다. (즉, 제약 조건에서 오류가 발생하면 동일한 오류를 사용자에게 다시 뱉지 마십시오. 오류를 이해할 수있게 만드십시오.)

(계단식 문제와 관련하여 : 그것은 좋은 일입니다. 모든 것을 올바르게하기 위해 계단식에 의존하기보다는 특정 다른 레코드를 먼저 삭제해야한다는 오류를 던지는 것을 선호합니다. 실제로 그렇게합니다.)

데이터베이스 제약 조건의 한 가지 문제점은 프로그램이 실패한 내용과 수정 방법에 대한 제한된 정보를 프로그램에 제공한다는 것입니다. 즉, 원활한 처리를 위해 응용 프로그램에서 제약 조건 검사를 반복해야하는 경우가 많으므로 데이터베이스 제약 조건 검사가 낭비됩니다.

이로 인해 데이터 무결성이 손상 될 위험이 있으므로 여기에서 장단점이 있습니다. 중요한 데이터의 경우 데이터 무결성을 보장하는 것이 거의 항상 성능보다 중요하며 데이터를 엉망으로 만드는 것보다 임의적 인 것처럼 보이더라도 트랜잭션을 실패하는 것이 훨씬 좋습니다.

따라서 제약 조건을 안전하게 제거하려면 제약 조건을 확인하지 않고도 데이터베이스를 변경할 수 없도록 데이터베이스 액세스를 보호해야합니다. 새로운 응용 프로그램을 작성하거나 데이터를 처리하는 임시 방법을 고안 할 때는 신뢰할 수 없습니다. 한 번의 실수만으로 데이터베이스가 손상 되었기 때문입니다.

따라서 데이터베이스 제약 조건을 없애려면 모든 응용 프로그램을 광범위하게 작성, 검토 및 테스트 할 수 있도록 데이터베이스로 수행 할 수있는 작업과 수행 할 수없는 작업을 미리 설정해야합니다. 모든 데이터베이스 요구 사항을 미리 설정해야하며 데이터베이스 요구 사항을 변경하려면 광범위한 작업이 필요합니다. 이것은 매우 특정한 경우에만 작동하는 얼어 붙은 폭포 방법입니다. (요구 사항을 설계, 구현 및 유지하는 것은 물 위를 걷는 것과 매우 유사합니다. 먼저 무언가를 얼려 야하며 충분히 얼지 않으면 결과가 비참 할 수 있습니다.)

이것이 작동하는 한 가지 사례는 PeopleSoft 및 SAP와 같은 대규모 엔터프라이즈 애플리케이션이며, 애플리케이션은 이미 거의 모든 작업을 수행하며이를 확장 할 수 있도록 신중하게 정의 된 방법이 있습니다. 매우 드문 다른 가능성이 있습니다.

따라서 매우 큰 엔터프라이즈 프로젝트에서 작업하거나 원치 않는 액체 물을 걸을 수 없다면 데이터베이스에 이러한 제약 조건을 남겨 두십시오.