이 질문은 SQL과 NoSQL의 차이점에 관한 것이 아닙니다. 나는 현재 이해가 안되는 부분에 대한 이론적 근거를 찾고 있습니다.
우리는 MVC5, Entity framework 6 코드를 먼저 사용하고 SQL Server 2008을 사용하여 새로운 프로젝트를 처음부터 시작했습니다. 아키텍트가 데이터베이스 스키마를 검토 할 때“비즈니스 로직”이므로 모든 외래 키 및 기타 제약 조건을 제거해야한다고 언급했습니다. 애플리케이션 코드의 비즈니스 계층 내에 적용해야합니다.
내 의견은 외래 키가 데이터 / 참조 무결성의 일부를 형성하며 실제로 비즈니스 논리를 모방하지 않는다는 것입니다. 비즈니스 로직을 참조가 적용되는시기 / 방법 / 방법을 제어하는 프로세스 및 검증이라고 생각합니다. 고유 제약 조건이 비즈니스 프로세스라는 것을 이해할 수는 있지만 이것은 논리를 보완하고 무결성의 일부를 형성합니다.
두 번째 논점은 데이터에 대한 NoSQL 접근 방식을 채택하는 것입니다. SQL-Server 2008의 사용,보고의 필요성, 테라 바이트로 확장되지 않는 데이터 및 Mongo, Raven 등과 같은 기술에 대한 고려가 부족하다는 점을 고려할 때 이례적이고 독창적이지 않았습니다.
전에 이런 시나리오를 본 사람이 있습니까? 누가 참조 데이터 용으로 설계된 SQL Server에서 NoSQL 접근 방식을 채택하고 외래 키를 원하지 않습니까?
답변
데이터베이스 스키마를 검토 할 때 모든 외래 키와 기타 제약 조건은 비즈니스 논리이므로 비즈니스 계층에 적용해야하므로 제거해야한다고 언급했습니다.
그런 다음 그는 바보이며, 코드베이스에서 발췌 한 일부는 언젠가 The Daily WTF 에서 끝날 것입니다 . 당신은 그의 접근 방식이 이해가되지 않는 것이 옳습니다.
참조 무결성 제약 조건이 “비즈니스 로직”이 아니라고 설명해보십시오. 그들은 것 자체 내장 된 검증과 정확성 표준입니다. 비즈니스 로직은 데이터로하는 일에 관한 것입니다. 무결성 은 데이터 자체가 손상되지 않도록하는 것입니다. 그리고 그것이 효과가 없다면 … 그는 책임이 있습니다. 그의 계획에 따라 피해를 다소 완화 시키거나 일하기 더 좋은 곳을 찾기 시작할 수 있습니다. (아니면 둘다.)
답변
아직 외래 키를 만들 이유가 없습니다
– 조엘 스폴 스키
담요 진술은 제쳐두고, 고유성 또는 외래 키 제약 조건을 사용하지 않기로 선택한 합법적이고 강력한 이유가 있음을 인정할 가치가 있습니다. 대부분 다음과 같이갑니다 :
- 공연. 원 자성 트랜잭션으로 무결성 검사를 수행하는 것은 무료가 아닙니다. 그리고 종종 데이터베이스는 확장하기 어려운 아키텍처에서 가장 어려운 부분입니다. 아마도 응용 프로그램 논리에서 이미 검사를 수행했으며 두 번째 성능 저하를 일으키지 않을 것입니다.
- 필요 부족. 아마도 당신의 데이터는 더러워 졌을 것입니다. 이것은 당신이하는 일에 크게 의존합니다.
외래 키의 문제점을 참조하십시오 .
그러나 귀하의 질문에있는 이유와 일치하지 않습니다.
이것은 비즈니스 로직이며 비즈니스 계층 내에 적용해야합니다.
이 이유는 조금 이상합니다. 고유성 및 기타 무결성 제약 조건은 ACID 데이터베이스의 도메인입니다. 응용 프로그램 코드는 SQLServer의 원 자성 및 무결성 보증에 접근 할 수 없습니다. 강력한 데이터 무결성이 필요한 경우 데이터베이스를 무시하는 것이 어리 석습니다.
두 번째 논점은 데이터 스토리지에 NoSQL 접근 방식을 채택하고 싶기 때문에 그러한 제한을 적용하고 싶지 않다는 것입니다.
두 번째 이유는 실제로 이유가 아닙니다. 결론입니다. 제약 조건이 정확성과 성능 사이의 균형을 이루는 것은 사실이지만 NoSQL 데이터베이스는 후자에 대해 편향되어 있습니다.
아마도 시스템 아키텍트는 이러한 합법적 인 이유를 염두에두고있을 것입니다. 아니면 어리석은 바보 일 수도 있습니다.
어쨌든 고유성 및 외래 키 제약 조건을 사용하지 않는 타당한 이유가 있습니다 (일반적 이지 는 않지만 ).
추신 당신이 외래 키를 원하지 않는다고 결론 지더라도 관계형 데이터베이스를 사용하는 것은 괜찮습니다. 일반화로서 관계형 데이터베이스는 NoSQL 데이터베이스보다 더 성숙합니다. 단일 노드로서 더욱 빨라질 수 있으며 NoSQL 추상화 가 그 위에 구축 될 수 있습니다 .