내 데이터가 관계형이거나 객체 지향적이라는 것을 어떻게 알 수 있습니까?

이 줄을 읽으십시오.

• 데이터가 본질적으로 객체 인 경우 객체 저장소 ( "NoSQL")를 사용하십시오. 관계형 데이터베이스보다 훨씬 빠릅니다.

• 데이터가 본질적으로 관계형 인 경우 관계형 데이터베이스의 오버 헤드가 그만한 가치가 있습니다.

에서-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

그렇다면 데이터가 본질적으로 관계형인지 객체 지향인지 어떻게 알 수 있습니까?

조각에 맞을 위험에 대비하여 나는 명확한 영어 정의를 시도 할 것입니다.

나를위한 "관계형 특성"은 다음과 같이 해석됩니다. 특정 유형의 모든 항목은 거의 동일한 속성을 가지므로 간단한 테이블을 디자인하기는 쉽지만 모든 테이블은 해당 테이블에 넣은 다음 SQL은 CRUD 및 검색을 수행합니다. 또한 모든 항목이 제한된 유형 세트 중 하나를 갖도록 데이터를 모델링 할 수있는 경우이 유형 세트에 해당하는 관계형 데이터 구조를 정의 할 수 있습니다.

"객체 속성"은 다음과 같이 번역됩니다. 유사한 유형의 항목은 다양한 속성을 가질 수 있으며 이러한 속성은 다양한 유형 및 속성을 가질 수 있습니다. 종종 이것은 (충분한 노력으로) 관계형 모델로 변환 될 수 있지만, 많은 테이블이 매우 드물게 채워져 매우 비효율적 인 LEFT OUTER 조인으로 인해 관계형 데이터베이스의 성능이 저하 될 수 있습니다 NOSQL 데이터베이스에.

나는 내 관점에서이 두 가지를 구분하는 엄격한 선이 없다고 말해야 할 것이다. 아마도 두 극단 사이에있는 많은 예제를 찾을 수있을 것입니다.

좋아, 이제 나는 모든 방향에서 저격수에게 자신을 열었다. 모든 의견을 환영합니다. 이 정의를 함께 개선 할 수 있는지 살펴 보자.

데이터는 둘 다입니다.

(엄격히 말하면 행동이 없기 때문에 본질적으로 객관적 일 수는 없지만 우리는 nitpick하지 않습니다).

RDBMS 또는 NoSQL 데이터베이스의 데이터 저장에 대한 결정은 데이터 자체의 실제 '본질'보다는 데이터를 사용하려는 방법에 따라 다릅니다 .

데이터에 대한 모든 정렬 탐색 경로를 지원하려는 경우 데이터에 액세스하고 표시하는 다른 방법이 있으므로 RDBMS에 데이터를 저장하려고 할 수 있습니다. 많은 양의 작업을 수행하려면 데이터베이스가 필요합니다. 예를 들어, '주문'데이터는 고객, 영업 사원, SKU (항목), 날짜, 지역 등을 통해 액세스 할 수 있습니다.

반면, 탐색 경로가 최소 인 경우 전체 오브젝트 만 저장할 수 있습니다. 예를 들어, 웹 프론트 엔드에서만 액세스하고 오래 저장하거나 많이 분석하지 않은 '바구니'는 NoSQL 저장소에 더 적합 할 수 있습니다. NoSQL 데이터 저장소로 수행하는 희생 (컬렉션 또는 키 값)은 컬렉션 간 관계없이 수행 할 수 있다는 것입니다 (탐색 경로, 임시 쿼리 또는 보고서의 경우) 앱을 사용하면 괜찮을 것입니다.

물론 서로 다른 이유로 데이터를 저장할 수는 있지만 자체 단점이 있습니다.

데이터는 '자연의 대상'또는 '자연의 관계'가 아닙니다. 모든 종류의 데이터는 관계형 또는 객체 모델 / 그래프 구조로 표현 될 수 있습니다. 적절한 것은 응용 프로그램에서 데이터를 사용하는 방법에 따라 다릅니다. 종종 둘 다 가질 수도 있습니다. 예를 들어 웹 사이트에서 사용되는 데이터는 관계형 데이터베이스에 저장 될 수 있지만 요청시 그래프 구조로로드 된 다음 메모리 내 키-값 저장소에 캐시됩니다.

개체 저장 / NoSql이 일부 종류의 데이터에 대해 관계형보다 빠르다는 진술은 단순히 잘못되었습니다. 중요한 것은 응용 프로그램 이 데이터 자체의 형식이 아니라 데이터를 사용 하는 방식입니다. 객체 저장소는 단위로 저장된 객체 그래프를로드하는 속도가 빠르지 만 많은 객체에 대한 임시 쿼리 나 많은 객체의 속성을 업데이트 할 때는 속도가 훨씬 느려집니다.

이 기사의 핵심 내용은 다음과 같습니다.

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

필자가 코드가 예를 들어 스페인의 고객 수를 약간의 논리로 얻는 경우 고객 목록을 스페인의 모든 고객으로 채운 다음 계산해서는 안된다는 점에서 저자가 좋은 지적을하고있는 것 같습니다. 고객 객체. (ORM이 당신을 향해 밀릴 수도 있습니다)

분명히 고객 데이터 구조 자체에서 그렇게 사용 될지 여부를 알 수 없습니다. '데이터'를 '응용 프로그램에서 사용하는 모든 정보'로 해석해야한다고 생각합니다. 이것이 집계 또는 '모든 X 관련 Y'와 같은 것을 포함하면 '데이터'는 원자 적 NoSql 접근법에 적합하지 않습니다.