데이터 베이스에 외래 키 제약 조건이 없는 9가지 이유(참조 무결성 검사) - 번역

외래키가 있으면 문제가 있는 부분들

잠재적인 데이터 무결성 문제

외래 키가 없다는 명백한 문제는 데이터베이스가 참조 무결성을 시행 할 수 없으며 상위 레벨에서 제대로 처리되지 않으면 일관성 없는 데이터

테이블 관계가 명확하지 않다

데이터베이스에서 외래 키가 부족하여 눈에 띄지 않는 또 다른 부정적인 영향은 스키마를 모르는 사람이 올바른 테이블을 찾고 테이블 관계를 파악하는 데 어려움을 겪는다는 것입니다. 이로 인해 데이터베이스에서 쿼리하고 report하는 데 심각한 문제가 발생할 수 있습니다.

왜? 데이터베이스에 foreign key를 없게 하나

데이터베이스에 외래 키가 없는 이유에 대해 알겠습니다.

아래에 제시된 이유는 데이터베이스에서 외래 키 제약 조건을 사용하지 말 것을 권장하지 않습니다. 그것은 많은 개발자, 아키텍트 또는 벤더들이 왜 그들을 사용하지 않는지에 대한 다양한 출처 에서 찾을 수 있었던 이유 모음 일 뿐입니다.

성능 문제

테이블에 외래 키가 활성되어 있으면 데이터 품질이 향상되지만 삽입, 업데이트 및 삭제 작업의 성능이 저하됩니다. 이러한 작업을 수행하기 전에 데이터베이스는 데이터 무결성을 위반하지 않는지 확인해야 합니다. 이것이 일부 아키텍트와 DBA가 외래 키를 아예 포기하는 이유입니다.

이는 특히 데이터를 트랜잭션 방식(한 번에 한 행씩)으로 처리하지 않고 대량으로 처리하는 데이터 웨어하우스 및 분석 데이터베이스의 경우입니다. 성능은 데이터 웨어하우징 및 비즈니스 인텔리전스의 모든 것입니다..

레거시 데이터

많은 데이터베이스가 설계될 때 데이터 품질과 무결성에 대해 그렇게 엄격하지 않았을 수 있는 이전 데이터베이스 및 소스의 레거시 데이터를 저장해야 했습니다. 오래된 더러운 데이터를 포함할 수 있도록 설계자는 가) 레거시 데이터를 정리하고 변환하는 방법(비용이 많이 드는 작업) 또는 나) 데이터베이스 수준에서 참조 무결성을 적용하는 것을 포기하는 방법을 선택할 수 있습니다. 일부 패키지 ERP 및 CRM 애플리케이션도 이 접근 방식을 사용합니다.

전체 테이블 다시 로드하기

데이터웨어 하우스, 스테이징 또는 인터페이스 데이터 베이스와 같은 일부 데이터베이스는 종종 외부 소스에서 데이터를 다시 로드해야 합니다. 이로 인해 다시 로드할 때 데이터가 일관되지 않게 됩니다.(부모 테이블이 비어 있는 동안 하위 테이블이 완전히 로드될 수 있습니다) 새로고침 시 키를 비활성화하여 무시할 수 있습니다. 그러나 이것은 추가적인 논리 및 복잡성과 또 다른 실패 지점을 야기합니다. 그리고 위에서 언급한 바와 같이 성과에 부정적인 영향을 미칩니다. 종종 비용이 이점보다 더 중요하며 개발자는 키를 신경쓰지 않습니다.

높은 수준 프레임워크

일부 응용 프로그램은 물리적 데이터베이스 위에 또 다른 논리적 계층을 만드는 프로그래밍 프레임워크를 사용합니다. 개발자는 데이터를 수정하기 위해 insert 또는 update 문을 사용하지 않고 API를 사용하거나 프레임워크가 백그라운드에서 모든 작업을 수행합니다. 이것은 ORM(Object-Relational Mapping) 프레임워크 또는 Ruby on Rails와 같은 프레임워크의 경우입니다. 이러한 도구는 참조 무결성을 처리하고 RDBMS와 함께 더 높은 수준의 데이터베이스 엔진을 만듭니다. 이러한 프레임워크는 데이터베이스 테이블 자체를 생성할 수 있으며 항상 왜래 키를 생성하는 것은 아닙니다. 이러한 도구를 사용하는 개발자는 자동으로 생성된 스키마를 거의 방해하지 않고 키 없이 그대로 둡니다.

Cross database relations

이것은 데이터베이스에 외래 키가 없는 올바른 이유가 아니라 일부가 누락될 수 있는 이유입니다. 일부 데이터베이스는 더 많은 물리적 데이터베이스와 엔진에 걸쳐 있으며 데이터베이스 전체에 걸쳐 있는 키를 만드는 것이 기술적으로 불가능할 수 있습니다.

SQL Server는 여기에서 좋은 예 입니다. 동일한 서버의 두 데이터베이스에 걸쳐 키를 생성할 수 없습니다. 그리고 이 아키텍처는 대규모 시스템에서 일반적입니다.

Database platform agnostic

이전 애플리케이션과 유사하게 일부 애플리케이션은 데이터베이스 플랫폼(DBMS)에 구애받지 않고 Oracle, SQL Server, DB/2 또는 Sybase와 같은 다양한 데이터베이스에서 작동할 수 있도록 설계되었습니다. 이것은 PeopleSoft(오라클 꺼)에 대해 읽은 내용입니다. 디자이너는 특정 플랫폼에 묶이기를 원하지 않았고 모든 논리를 응용 프로그램 계층으로 푸시하여 데이터베이스 계층을 가능한 한 단순하게 유지했습니다.

Open for change

Oracle을 고수하면서 애플리케이션에 대해 들었던 또 다른 이야기인 Oracle E-Business Suite는 가능한 한 사용자 정의가 가능하도록 설계되었다는 것입니다. Oracle은 견고한 토대를 제공하고 구현 팀이 설계의 가능한 많은 측면을 결정할 수 있도록 탄력성을 부여했습니다. 적어도 이것이 그들이 말하는 것입니다. 아마도 그 이유는 이전 요점과 같거나 다음 요점이었을 것입니다.

Lazy architect

데이터베이스를 생성할 때 데이터를 저장하려면 일부 테이블과 열을 생성해야 합니다. 이것은 최소값입니다. 그러나 기본, 고유, 외래 키 또는 제약 조건과 같이 데이터 일관성을 유지하는 구조를 만들 필요는 없습니다. 약간의 노력이 필요하며 즉각적인 이점이 없습니다. 일부 아키텍트와 DBA는 그 부분을 무시합니다.

Keep model a secret

어쩌면 이것은 먼 이야기일 수도 있지만 때로는 사람들이 다른 사람들이 너무 쉽게 알고 너무 많이 알기를 원하지 않기 때문일 수도 있습니다. 일반적으로 사람들은 필요하고 무엇과도 바꿀 수 없는 것을 원합니다. 설명이 필요 없는 완벽한 디자인은 그것들을 쓸모 없게 만들 수도 있습니다. 이것은 이 출처 블로그 주인의 개인적인 이론입니다.

출처:

https://dataedo.com/blog/why-there-are-no-foreign-keys-in-your-database-referential-integrity-checks

9 reasons why there are no foreign keys constraints in your database (referential integrity checks) - Dataedo Blog