SQL Server 내의 NoSQL

이 질문은 SQL과 NoSQL의 차이점에 관한 것이 아닙니다. 나는 현재 이해가 안되는 부분에 대한 이론적 근거를 찾고 있습니다.

우리는 MVC5, Entity framework 6 코드를 먼저 사용하고 SQL Server 2008을 사용하여 새로운 프로젝트를 처음부터 시작했습니다. 아키텍트가 데이터베이스 스키마를 검토 할 때“비즈니스 로직”이므로 모든 외래 키 및 기타 제약 조건을 제거해야한다고 언급했습니다. 애플리케이션 코드의 비즈니스 계층 내에 적용해야합니다.

내 의견은 외래 키가 데이터 / 참조 무결성의 일부를 형성하며 실제로 비즈니스 논리를 모방하지 않는다는 것입니다. 비즈니스 로직을 참조가 적용되는시기 / 방법 / 방법을 제어하는 프로세스 및 검증이라고 생각합니다. 고유 제약 조건이 비즈니스 프로세스라는 것을 이해할 수는 있지만 이것은 논리를 보완하고 무결성의 일부를 형성합니다.

두 번째 논점은 데이터에 대한 NoSQL 접근 방식을 채택하는 것입니다. SQL-Server 2008의 사용,보고의 필요성, 테라 바이트로 확장되지 않는 데이터 및 Mongo, Raven 등과 같은 기술에 대한 고려가 부족하다는 점을 고려할 때 이례적이고 독창적이지 않았습니다.

전에 이런 시나리오를 본 사람이 있습니까? 누가 참조 데이터 용으로 설계된 SQL Server에서 NoSQL 접근 방식을 채택하고 외래 키를 원하지 않습니까?

sql sql-server nosql

— 앤디 클라크
소스

조언의 근거에 대해 시스템 설계자와 상담하십시오. 그는 귀하의 특정 사례에 적용되는 매우 좋은 이유가 있거나 (앱이 무엇인지 정확히 알지 않고도 추측 할 수없는 이유), 또는 단지 무능합니다.

— Arseni Mourzenko

FK, CHECK 제약 조건이없는 많은 데이터베이스가 비슷한 방식으로 구현 된 것을 보았습니다. 데이터베이스 아키텍처, 참조 무결성 등에 대해 전혀 모르는 경험이없는 코더가 데이터베이스를 설계 할 때마다 데이터베이스가 논의되었습니다. 단순히 무능하다고 가정하는 대신 동료.

— Arseni Mourzenko 2016 년

약간 혼란 스러워요. Entity framework (코드 우선) 사용에 대해 언급하지는 않습니다 (C # 의미에서 Objects를 만든 다음 Entity framework가 데이터베이스 등가물을 처리하도록 함을 의미하지는 않습니다.이 경우 FK 등을 추가 / 제거하는 것은 엔티티 프레임 워크 현명 노력의 운동 (일종의 노래 돼지를 가르치려고 노력에 대한 마크 트웨인의 인용 등의입니까?)

— 푼

스스로 "건축가"라고 주장하지만 실제로는 더 큰 시스템을 코딩하거나 유지 관리 한 경험이없는 사람들이 너무 많습니다.

— Doc Brown

관련 : thedailywtf.com/articles/The-Mythical-Business-Layer . "생각해 보면 소프트웨어 응용 프로그램의 거의 모든 코드는 비즈니스 로직입니다." 이것은 데이터베이스로 확장됩니다. "하지만 응용 프로그램 코드의 거의 모든 부분이 비즈니스 로직이라는 점을 명심해야합니다. 이미 충분한 도구가 있습니다. 응용 프로그램 에는 일반 계층이 필요하지 않습니다 (강조 광산). 이것을 추천하는 사람은 아마도 데이터베이스를 하나의 일반 레이어로 바꾸려고합니다. 요컨대, 그들은 유행어를 현실보다 위에 놓을 가능성이 높습니다.

— jpmc26

답변:

데이터베이스 스키마를 검토 할 때 모든 외래 키와 기타 제약 조건은 비즈니스 논리이므로 비즈니스 계층에 적용해야하므로 제거해야한다고 언급했습니다.

그런 다음 그는 바보이며, 코드베이스에서 발췌 한 일부는 언젠가 The Daily WTF 에서 끝날 것입니다 . 당신은 그의 접근 방식이 이해가되지 않는 것이 옳습니다.

참조 무결성 제약 조건이 "비즈니스 로직"이 아니라고 설명해보십시오. 그들은 것 자체 내장 된 검증과 정확성 표준입니다. 비즈니스 로직은 데이터로하는 일에 관한 것입니다. 무결성 은 데이터 자체가 손상되지 않도록하는 것입니다. 그리고 그것이 효과가 없다면 ... 그는 책임이 있습니다. 그의 계획에 따라 피해를 다소 완화 시키거나 일하기 더 좋은 곳을 찾기 시작할 수 있습니다. (아니면 둘다.)

— 메이슨 휠러
소스

건축가 가이 일을하는 이유가 무엇인지 찾기 위해 약간 더 외교적 인 대답이있었습니다. 냉정하게 반성하자면, 나는이 답을 대신 사용하고 있습니다.

— Blrfl

우와, 나쁜 건축 시도가 다른 곳에서 일해야하는 이유는 무엇입니까? 젠장, 내가 그 전망을 취하면 어디에서나 계속 일할 수 없었을 것입니다.

— Kzqai

@Kzqai에는 아키텍처를 근본적으로 오해하는 건축가도 있습니다. 이것은 지시문 595 처럼 들리기 시작합니다. 그렇습니다. 누군가 망치를 사용하여 나사를 나무 조각에 넣으려고하면 도구를 잘못 사용하여 무언가를 만들도록 강요하지 않는 사람을 찾을 것입니다.

참조 무결성 은 데이터베이스 이론에서 핵심 주제이며 실제 환경에서이를 지원하는 모든 데이터베이스는 말할 것도 없습니다. 분명히 Andy의 동료는 그의 분석에서 정확하고, 나머지 학계와 직업 계는 100 % 잘못되었습니다. The Daily WTF 언급에 대한 보너스 포인트 .

@AndyClark 이걸 끝내야합니다. 그 이유는 회사의 핵심에 핵폭탄이 있기 때문입니다. 배설물이 인공 호흡기에 충돌하는 것은 시간 문제입니다. 이런 일이 발생하면 일자리를 찾고있는 최악의 시나리오 인 72 시간 근무를하는 것이 운이 좋을 것입니다. 소득이있을 때 일자리를 찾는 것이 더 좋습니다.

— ArTs

아직 외래 키를 만들 이유가 없습니다

- 조엘 스폴 스키

담요 진술은 제쳐두고, 고유성 또는 외래 키 제약 조건을 사용하지 않기로 선택한 합법적이고 강력한 이유가 있음을 인정할 가치가 있습니다. 대부분 다음과 같이갑니다 :

공연. 원 자성 트랜잭션으로 무결성 검사를 수행하는 것은 무료가 아닙니다. 그리고 종종 데이터베이스는 확장하기 어려운 아키텍처에서 가장 어려운 부분입니다. 아마도 응용 프로그램 논리에서 이미 검사를 수행했으며 두 번째 성능 저하를 일으키지 않을 것입니다.
필요 부족. 아마도 당신의 데이터는 더러워 졌을 것입니다. 이것은 당신이하는 일에 크게 의존합니다.

외래 키의 문제점을 참조하십시오 .

그러나 귀하의 질문에있는 이유와 일치하지 않습니다.

이것은 비즈니스 로직이며 비즈니스 계층 내에 적용해야합니다.

이 이유는 조금 이상합니다. 고유성 및 기타 무결성 제약 조건은 ACID 데이터베이스의 도메인입니다. 응용 프로그램 코드는 SQLServer의 원 자성 및 무결성 보증에 접근 할 수 없습니다. 강력한 데이터 무결성이 필요한 경우 데이터베이스를 무시하는 것이 어리 석습니다.

두 번째 논점은 데이터 스토리지에 NoSQL 접근 방식을 채택하고 싶기 때문에 그러한 제한을 적용하고 싶지 않다는 것입니다.

두 번째 이유는 실제로 이유가 아닙니다. 결론입니다. 제약 조건이 정확성과 성능 사이의 균형을 이루는 것은 사실이지만 NoSQL 데이터베이스는 후자에 대해 편향되어 있습니다.

아마도 시스템 아키텍트는 이러한 합법적 인 이유를 염두에두고있을 것입니다. 아니면 어리석은 바보 일 수도 있습니다.

어쨌든 고유성 및 외래 키 제약 조건을 사용하지 않는 타당한 이유가 있습니다 (일반적 이지 는 않지만 ).

추신 당신이 외래 키를 원하지 않는다고 결론 지더라도 관계형 데이터베이스를 사용하는 것은 괜찮습니다. 일반화로서 관계형 데이터베이스는 NoSQL 데이터베이스보다 더 성숙합니다. 단일 노드로서 더욱 빨라질 수 있으며 NoSQL 추상화 가 그 위에 구축 될 수 있습니다 .

— 폴 드레이퍼
소스

나는 Joel이 바보가 아니라, 포드 캐스트에서 재치있는 대답은 아무 설명도없이 IMHO는 어떤 바보의 진술보다 가치가 적다고 말합니다.

— Martin Ba

Joel은 데이터베이스 담당자가 아닌 스프레드 시트 담당자이므로 표준 관계형 데이터베이스 관행에 대한 그의 무지는 놀라운 일이 아닙니다. :-)

— Eric King

Joel의 상황에 맞는 실제 인용문은 LINQ와 같은 기술로 외래 키를 설정 해야하는 이유를 제공합니다. Joel은 데이터베이스 관리자가 아니며 블로그를 검색하고 오랜 독자가되어서 주제에 대해 이야기하거나 데이터베이스 최적화, 데이터 모델 설계 등에 대한 조언을 제공 할 수있는 정보를 찾을 수 없습니다. Joel 's awesome 그러나 그는 지금도 아니었다. -데이터베이스 또는 데이터 모델링 분야의 전문가. 그것은 화합물의 관심사 또는 샌드위치에 대해 아인슈타인을 인용하는 것과 같습니다. (XKCD 참조, 환영합니다.) :)

— BrianH

Joel Spolsky는 강력하고 논쟁의 여지가있는 의견으로 유명합니다. 페이지 의 Fogbugz은 고유의 언어로 작성 ; 의존성 주입이 너무 복잡합니다 (btw, 이것은 닫히기 전에 Stackoverflow에서 가장 논란의 여지가있는 대답 이었습니다 ) . XML 데이터베이스는 느립니다 . 등

— BlueRaja - 대니 Pflughoeft

@BlueRaja : 음 ... XML 데이터베이스 는 특히 관계형 데이터베이스에 비해 느립니다. 언제부터 논란의 여지가 있거나 의견이 있습니까?

— 메이슨 휠러