데이터베이스 또는 코드의 테이블 간 관계를 정의해야합니까?

내 경험상, 과거에 읽은 많은 프로젝트는 데이터베이스에 관계 정의가 없었고 대신 소스 코드에서만 정의했습니다. 그래서 데이터베이스와 소스 코드에서 테이블 간의 관계를 정의 할 때의 장점 / 단점이 무엇인지 궁금합니다. 더 넓은 질문은 캐스케이드, 트리거, 프로 시저와 같은 최신 데이터베이스의 다른 고급 기능에 관한 것입니다. 내 생각에는 몇 가지 요점이 있습니다.

데이터베이스에서 :

• 설계에서 정확한 데이터. 유효하지 않은 데이터를 일으킬 수있는 응용 프로그램 오류를 방지하십시오.

• 응용 프로그램은 데이터 무결성을 확인하기 위해 더 많은 쿼리를 작성해야하므로 데이터를 삽입 / 업데이트 할 때 응용 프로그램으로의 네트워크 왕복을 줄입니다.

소스 코드에서 :

• 더 유연합니다.

• 때때로 데이터베이스 간 관계가있을 수 있으므로 여러 데이터베이스로 확장 할 때 더 좋습니다.

• 데이터 무결성에 대한 통제력 강화. 데이터베이스는 응용 프로그램이 데이터를 수정할 때마다 확인할 필요가 없습니다 (복잡성은 O (n) 또는 O (n log n) (?) 일 수 있음). 대신 응용 프로그램에 위임됩니다. 그리고 응용 프로그램에서 데이터 무결성을 처리하면 데이터베이스를 사용하는 것보다 더 자세한 오류 메시지가 발생한다고 생각합니다. 예 : API 서버를 생성 할 때 데이터베이스에 관계를 정의하고 참조 엔터티가 존재하지 않는 것과 같은 문제가 발생하면 메시지와 함께 SQL 예외가 발생합니다. 간단한 방법은 "내부 서버 오류"가 있음을 클라이언트에게 500을 반환하는 것이며 클라이언트는 무엇이 잘못되었는지 알 수 없습니다. 또는 서버가 메시지를 구문 분석하여 무엇이 잘못되었는지 알아낼 수 있습니다. 제 생각에 추악하고 오류가 발생하기 쉬운 방법입니다. 응용 프로그램에서이를 처리하도록 허용하면

다른 것이 있습니까?

편집 : Kilian이 지적했듯이 성능 및 데이터 무결성에 대한 나의 요지는 매우 잘못되었습니다. 그래서 나는 내 요점을 수정하기 위해 편집했습니다. 데이터베이스를 처리하는 것이 더 효율적이고 강력한 접근 방법이라는 것을 완전히 이해하고 있습니다. 업데이트 된 질문을 확인하고 그것에 대해 몇 가지 생각을하십시오.

편집 : 모두 감사합니다. 내가받은 답변은 제약 조건 / 관계가 데이터베이스에 정의되어야한다고 지적합니다. :). 이 질문의 범위를 벗어나기 때문에 질문이 하나 더 있습니다. 방금 별도의 질문으로 게시했습니다 : API 서버의 데이터베이스 오류 처리 . 통찰력을 남겨주세요.

TL; DR : 관계 제한 조건이 데이터베이스에 있어야합니다.

응용 프로그램이 충분하지 않습니다.

데이터베이스 간의 관계를 강제 로 적용하려면 응용 프로그램에서 관계를 강화해야 할 수도 있습니다 .

그러나 먼저 사용중인 데이터베이스 소프트웨어의 설명서를 확인하고 기존 제품 제안을 확인해야한다고 지적합니다. 예를 들어 Postgres 및 MySQL 위에 클러스터링 오퍼가 있습니다.

그리고 응용 프로그램에서 약간의 유효성 검사 가 필요하더라도 목욕 물로 아기를 버리지 마십시오 . 결국,해야 할 일이 적을수록 더 좋습니다.

마지막으로, 미래의 확장 성 문제가 걱정된다면 응용 프로그램이 확장되기 전에 크게 변경되어야 할까봐 걱정됩니다. 경험상 10 배가 될 때마다 다시 디자인해야하므로 확장 성 문제를 예측하지 못하는 데 너무 많은 돈을 들이지 말고 실제로 돈을 사용하여 실제로 문제가있는 지점에 도달하도록하겠습니다.

응용 프로그램이 충분히 정확하지 않습니다.

사용하는 데이터베이스가 점검을 잘못 구현했을 가능성이있는 것과 응용 프로그램 이 점검을 잘못 구현했을 가능성이 있습니까?

그리고 어느 것을 가장 자주 변경합니까?

나는 데이터베이스가 언제나 정확하다는 것에 내기를 걸었다 .

개발자가 충분히 배포되지 않았다고 생각합니다.

응용 프로그램이 데이터 무결성을 확인하기 위해 더 많은 쿼리를 작성해야하므로 데이터를 삽입 / 업데이트 할 때 응용 프로그램으로의 네트워크 왕복을 줄입니다.

붉은 깃발 ! ¹

당신이 생각하는 경우 :

• 기록이 있는지 확인
• 그렇지 않은 경우 레코드를 삽입하십시오

당신은 실패 의 가장 기본적인 동시성 문제를 : 당신이 가서 다른 프로세스 / 스레드가 레코드를 추가 할 수 있습니다.

당신이 생각하는 경우 :

• 기록이 있는지 확인
• 그렇지 않은 경우 레코드를 삽입하십시오
• 레코드가 중복으로 삽입되었는지 확인

당신은 실패 MVCC을 설명하기 : 당신이 가지고있는 데이터베이스의 뷰가 사용자의 트랜잭션이 시작되는 시간에 스냅 샷입니다; 발생하고 있거나 커밋 되지 않은 모든 업데이트를 표시 하지는 않습니다 .

여러 세션에서 제약 조건을 유지 관리하는 것은 정말 어려운 문제입니다. 데이터베이스에서 해결되어 기쁩니다.

¹ 데이터베이스가 Serializable 속성을 올바르게 구현하지 않는 한; 그러나 실제로는 거의 없습니다.

마지막:

그리고 응용 프로그램에서 데이터 무결성을 처리하면 데이터베이스를 사용하는 것보다 더 자세한 오류 메시지가 표시됩니다. 예 : API 서버를 만들 때 데이터베이스에서 관계를 정의하고 참조 엔터티가 존재하지 않는 것과 같은 문제가 발생하면 메시지와 함께 SQL 예외가 발생합니다.

오류 메시지를 구문 분석하지 마십시오. 프로덕션 등급 데이터베이스를 사용하는 경우 구조적 오류를 리턴해야합니다. 적어도 무엇이 잘못되었는지를 나타내는 오류 코드가있을 것입니다.이 코드를 기반으로 적절한 오류 메시지를 작성할 수 있습니다.

대부분의 코드는 충분합니다. 참조 된 외래 키가 존재하지 않는다는 오류 코드가있는 경우이 테이블에는 외래 키가 하나만있을 가능성이 있으므로 코드에서 문제가 무엇인지 알 수 있습니다 .

또한 정직하게 말하면 대부분의 경우 우아하게 오류를 처리하지 않습니다. 단지 그들 중 많은 수가 있기 때문에 당신은 그들 모두를 설명하지 못할 것입니다 ...

... 위 의 정확성 지점 과 연결됩니다 . 데이터베이스 제약 조건이 발생하여 처리되지 않아 "500 : 내부 서버 오류"가 표시 될 때마다 코드에서 처리하는 것을 잊었 기 때문에 데이터베이스가 저장되었음을 의미합니다.

데이터베이스는 응용 프로그램이 데이터를 수정할 때마다 데이터 무결성을 확인할 필요가 없습니다.

이것은 매우 잘못된 지침입니다. 이 목적을 위해 데이터베이스가 만들어졌습니다. 데이터 무결성 검사가 필요하고 (필요하지 않다고 생각되면 실수로 잘못 판단한 경우) 데이터베이스를 처리하도록하는 것이 응용 프로그램 논리에서 수행하는 것보다 훨씬 효율적이고 오류가 덜 발생하기 쉽습니다.

(세계에서 가장 의지), 응용 프로그램이되므로 제약은 데이터베이스 내에서 거짓말을해야 하지 지금이 데이터베이스에 액세스 할 수있는 유일한 일이 될.

어느 시점에서 데이터베이스 내에 스크립트로 수정 된 수정 프로그램이 있거나 배포시 한 테이블에서 다른 테이블로 데이터를 마이그레이션해야 할 수 있습니다.

또한 "오후 큰 고객 X가 오늘 오후에 응용 프로그램 데이터베이스로 가져온이 뛰어난 데이터 시트가 필요합니다"와 같은 다른 요구 사항도 얻을 수 있습니다.이 경우 더티 SQL 스크립트가 완료 될 때 응용 프로그램 코드를 적용 할 수있는 고급 스러움이 없습니다. 제 시간에.

데이터베이스 수준의 무결성으로 베이컨을 절약 할 수 있습니다.

또한 퇴사 후이 회사에서 귀하의 역할을 맡아 데이터베이스를 변경하는 개발자를 상상하십시오.

데이터베이스에 FK 제약 조건이 없으면 테이블을 변경하기 전에 테이블의 관계를 알 수 있도록 미워합니까? ( 단서, 예는 그렇습니다 )

데이터베이스에 관계가 있어야합니다.

다른 답변에서 언급했듯이 제약 조건 검사 성능은 응용 프로그램 내부보다 데이터베이스 내부에서 훨씬 더 좋습니다. 데이터베이스 제약 조건 검사는 데이터베이스가 능숙한 것 중 하나입니다.

추가 된 유연성 (예 : 알려진 교차 데이터베이스 참조)이 필요한 경우 의도적으로 고려하여 제약 조건을 제거 할 수 있습니다. 데이터베이스 내에서 일관성을 유지한다는 것은 이러한 제한 조건과 참조 무결성의 확실성을 수정할 수있는 옵션이 있음을 의미합니다.

• 우리는 더 이상 하나의 백엔드 <-> 하나의 프론트 엔드 세계에 살고 있지 않습니다.
• 대부분의 솔루션에는 웹 프론트 엔드, 모바일 프론트 엔드, 배치 프론트 엔드 및 iPad 프론트 엔드 등이 포함됩니다.
• 데이터베이스 엔진에는 참조 무결성을 강화하기 위해 최적화 된 수천 개의 테스트 코드가 이미 있습니다.

도메인 문제 해결 코드를 작성할 때 참조 무결성 적용 코드를 작성하고 테스트 할 여유가 있습니까?

데이터베이스 수준에서 데이터 무결성, 제약 조건, 관계 등을 확인하지 않으면 프로덕션 데이터베이스 액세스 권한이있는 모든 사람 (DB 액세스 도구를 포함한 다른 클라이언트를 통해)이 데이터를 엉망으로 만드는 것이 훨씬 쉬워집니다.

데이터베이스 수준에서 가장 엄격한 데이터 무결성을 유지하는 것이 좋습니다. 날 믿어, 이것은 사소한 시스템에서 시간이 지남에 따라 엄청난 두통을 덜어 줄 것입니다. 또한 신중하게 생각하면 응용 프로그램 논리 오류 또는 비즈니스 요구 사항 오류 및 불일치가 더 빨리 발생합니다.

이에 대한 참고로, 가능한 한 표준화되고 원자적인 방식으로 데이터베이스를 설계하십시오. "하나님"테이블이 없습니다. 단일 책임을 갖고 모든 열에 대해 신중하게 검증 된 개별 테이블이 매우 작은 여러 테이블을 사용하여 데이터베이스를 최대한 간단하게 설계하는 데 많은 노력을 기울이십시오. 데이터베이스는 데이터 무결성의 마지막 보호자입니다. 성의 성채를 나타냅니다.

대부분의 사람들은 본질적으로 "예, 일반적으로 말하는 너는 항상 데이터베이스의 관계를 정의합니다." 그러나 컴퓨터 과학 분야가 매우 쉬운 경우에는 "소프트웨어 엔지니어"대신 "소프트웨어 설명서 리더"라고합니다. 나는 제약이 있어야 하는 좋은 이유가 없다면 제약 조건이 데이터베이스에 들어가야한다는 것에 동의합니다. 따라서 특정 상황에서 좋은 것으로 간주 될 수있는 몇 가지 이유를 제시하겠습니다 .

중복 코드

때로는 데이터베이스가 처리 할 수있는 특정 기능이 응용 프로그램 코드에 자연스럽게 존재할 수 있습니다. 데이터베이스에 제약 조건과 같은 것을 추가하는 것이 중복되는 경우 DRY 원칙을 위반하기 때문에 기능을 복제하지 않는 것이 좋으며 데이터베이스와 응용 프로그램 코드를 동기화 상태로 유지하는 저글링 동작을 악화시킬 수 있습니다.

노력

데이터베이스가 이미 고급 기능을 사용하지 않고 수행해야하는 작업을 수행하는 경우 시간, 비용 및 노력을 어디에 두어야하는지 평가할 수 있습니다. 제약 조건을 추가하여 치명적인 오류를 방지하여 회사에 많은 돈을 절약 할 수 있다면 그만한 가치가있을 것입니다. 유지해야하지만 제약 조건을 위반하지 않는 제약 조건을 추가하는 경우 시간을 낭비하고 코드베이스를 오염시키는 것입니다. 여기에 작동 단어가 보장 됩니다.

능률

일반적으로 좋은 이유는 아니지만 경우에 따라 특정 성능 요구 사항이있을 수 있습니다. 응용 프로그램 코드가 데이터베이스보다 빠른 방식으로 특정 기능을 구현할 수 있고 추가 성능이 필요한 경우 응용 프로그램 코드에서 기능을 구현해야합니다.

제어

효율성과 다소 관련이 있습니다. 때로는 기능이 구현되는 방식에 대해 매우 세밀한 제어가 필요하며 데이터베이스를 처리하도록하면 블랙 박스 뒤에 숨겨야합니다.

결산 점

• 데이터베이스는 코드로 작성됩니다. 자신의 코드로는 할 수없는 마술은 없습니다.
• 무료는 없습니다. 제약 조건, 관계 등은 모두 CPU주기를 사용합니다.
• NoSQL 세계의 사람들은 전통적인 관계형 기능 없이도 잘 지냅니다. 예를 들어 MongoDB에서 JSON 문서의 구조는 전체 데이터베이스를 지원하기에 충분합니다.
• 고급 데이터베이스 기능을 맹목적으로 무지하게 사용한다고해서 어떠한 이점도 보장 할 수는 없습니다. 실수로 나중에 깨뜨릴 수있는 무언가를 만들 수도 있습니다.
• 특정 요구 사항이나 제약 조건을 나열하지 않고 매우 일반적인 질문을했습니다. 귀하의 질문에 대한 실제 답변은 "의존"입니다.
• 이것이 엔터프라이즈 규모 문제인지 여부를 지정하지 않았습니다. 다른 답변은 고객 및 데이터 무결성과 같은 것에 대해 이야기하지만 때로는 중요하지 않은 경우가 있습니다.
• 전통적인 SQL Relational 데이터베이스에 대해 이야기하고 있다고 가정합니다.
• 저의 관점은 소규모 (최대 50 개의 테이블) 프로젝트에서 수많은 제약 조건과 외래 키를 사용 하지 않고 단점을 눈치 채지 못한 것 입니다.

마지막으로 말할 것은 데이터베이스에 기능을 배치해서는 안된다는 것을 알게 될 것입니다. 확실하지 않은 경우 일반적으로 데이터베이스 기능이 실제로 제대로 작동하므로 데이터베이스 기능을 사용하는 것이 좋습니다.

언제나 그렇듯이 많은 답변이 있습니다. 나를 위해 간단한 규칙을 찾았습니다 (모델 중심 접근법에서만 작동합니다). 일반적으로 다른 계층의 응용 프로그램에만 중점을 둡니다.

모델이 여러 엔터티로 구성되어 있고 엔터티간에 종속성이있는 경우 지속성 계층은 이러한 종속성을 가능성과 함께 반영해야합니다. 따라서 RDBMS를 사용하는 경우 외래 키도 사용해야합니다. 이유는 간단합니다. 그렇게하면 데이터는 항상 구조적으로 유효합니다.

이 지속성 계층에 대한 작업을 수행하는 모든 인스턴스가이를 유지할 수 있습니다. 인터페이스 (서비스)를 통해이 계층을 캡슐화한다고 가정합니다. 여기 디자인이 끝나고 현실이 시작되는 지점이 있습니다.

요점, 특히 데이터베이스 간 참조를 살펴보십시오 . 이 경우 RDBMS 자체에 구현 된 참조가 아니라 서비스에 참조가 있어야합니다. 그러나이 방법을 따르기 전에 디자인 중에 이미 이것을 고려하는 것이 낫지 않습니까?

내가 이미 알고 있다면 다른 DB에 저장해야 할 부분이 있다는 것을 의미합니다.이를 이미 거기에 놓고 별도의 모델로 정의 할 수 있습니다. 권리?

또한 코드에서 이것을 구현하는 것이 더 유연 하다는 것을 지적하고 있습니다. 맞습니다.하지만 불완전한 디자인을 다루는 것처럼 들리지 않습니까? 스스로에게 더 많은 유연성이 필요한 이유는 무엇입니까?

DB 의 무결성 검사 로 인한 성능 문제 는 실제가 아닙니다. RDBMS는 이러한 구현을 사용자가 구현 한 것보다 훨씬 빠르게 확인할 수 있습니다. 왜? RDBMS는 미디어 중단을 처리해야합니다. 그리고 통계 아소를 사용하여 그러한 검사를 최적화 할 수 있습니다

보시다시피 모든 것이 디자인으로 돌아옵니다. 물론 지금 말할 수 있지만 알 수없는 요구 사항이 표시되면 게임 체인저는 어떻습니까? 그렇습니다. 그러나 그러한 변경은 설계 및 계획되어야합니다. ;영형)

아주 좋은 답변이 있지만 더 많은 포인트가 있습니다.

데이터 무결성은 데이터베이스가 수행하도록 설계된 것입니다

응용 프로그램 수준에서 FK 삭제와 같은 적절한 동시 처리를 수행하는 것은 끔찍합니다.

데이터 무결성에 대한 전문 지식은 DBA입니다

프로그램 수준에서 삽입, 업데이트, 대량 업데이트, 대량 삽입, 대량 삭제 ...
씬 클라이언트, 씩 클라이언트, 모바일 클라이언트 ....
데이터 무결성은 프로그래머의 전문 지식이 아닙니다-많은 중복 코드 및 누군가가 엉망이됩니다. 그것은 위로

해킹 당했다고 가정하십시오-어느 쪽이든 문제가 있지만 데이터베이스에 무결성 보호가 없으면 해커가 작은 구멍을 통해 많은 피해를 입을 수 있습니다

SQL 또는 TSQL을 통해 직접 데이터를 조작해야 할 수도 있습니다.
모든 데이터 규칙을 기억할 사람은 없습니다.

귀하의 질문은 이해가되지 않습니다 : 데이터베이스를 변경할 수 있다면 코드입니다. 데이터베이스를 변경할 수 없다면 다른 곳에서 제약 조건을 만들어야합니다.

변경할 수있는 데이터베이스는 루비, 자바 스크립트, c # 또는 ada 라인만큼이나 많은 코드입니다.

시스템에서 제약 조건을 어디에 두어야하는지에 대한 질문은 신뢰성, 비용 및 개발 용이성으로 요약되어야합니다.

여기에 좋은 답변이 많이 있습니다. 언어 Y로 작성된 앱이 있으면 Y로 데이터베이스 제약 조건과 유사한 코드를 만들 수 있습니다. 그런 다음 누군가 언어 Z를 사용하여 데이터베이스에 액세스하려면 동일한 코드를 다시 작성해야합니다. 구현이 정확히 동일 하지 않은 경우 하나님은 당신을 도와줍니다 . 또는 지식이 풍부한 비즈니스 사용자가 Microsoft Access를 사용하여 데이터베이스에 연결할 때.

내 경험에 따르면 사람들이 데이터베이스 제약 조건을 사용하지 않으려는 경우 실제로 잘못된 방식으로 무언가를 시도하고 있기 때문입니다. 예를 들어, 그들은 데이터를 벌크로드하려고 시도하고 있으며, null이 아닌 열을 잠시 null로 남겨두고 싶습니다. 널 (null)이 아닌 제한 조건을 중요하게 한 상황이 "이 경우에는 발생하지 않을 수 있기 때문에"나중에 수정합니다. 두 가지 유형의 데이터를 같은 테이블에 삽입하려고 할 때 다른 예가 있습니다.

더 숙련 된 사람들은 물러서서 제약 조건을 우회하지 않는 솔루션을 찾습니다. 솔루션은 비즈니스가 변화했기 때문에 더 이상 제약이 더 이상 적절하지 않을 수 있습니다.