지금 당분간 답변을 시도했지만 알아낼 수없는 질문이 있습니다.
CouchDB 문서를 어떻게 디자인하거나 분할합니까?
예를 들어 블로그 게시물을 살펴보십시오.
이를 수행하는 반 "관계형"방법은 몇 가지 개체를 만드는 것입니다.
- 게시하다
- 사용자
- 논평
- 꼬리표
- 단편
이것은 상당한 의미가 있습니다. 하지만 나는 같은 것을 모델링하기 위해 (대단한 모든 이유로) couchdb를 사용하려고 노력하고 있으며 매우 어려웠습니다.
대부분의 블로그 게시물은이를 수행하는 방법에 대한 쉬운 예를 제공합니다. 그들은 기본적으로 같은 방식으로 나누지 만 각 문서에 '임의'속성을 추가 할 수 있다고 말하는데, 확실히 좋습니다. 따라서 CouchDB에 다음과 같은 것이 있습니다.
- 게시물 (문서에 "의사"모델 태그 및 스 니펫 포함)
- 논평
- 사용자
어떤 사람들은 거기에 Comment와 User를 던질 수 있다고 말할 것입니다.
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
매우 멋져 보이고 이해하기 쉽습니다. 또한 모든 Post 문서에서 댓글 만 추출한 뷰를 작성하여 사용자 및 태그와 마찬가지로 댓글 모델로 가져 오는 방법도 이해합니다.
하지만 "내 전체 사이트를 하나의 문서에 넣지 않는 이유는 무엇입니까?"라고 생각합니다.
site {
domain: "www.blog.com"
owner: "me"
pages {
page {
title: "Blog"
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
post {
id: 18091890192984
title: "Second Post"
...
}
}
}
}
}
원하는 것을 쉽게 찾을 수 있습니다.
그러면 제가 가진 질문은 문서를 더 작은 문서로 나눌 때 또는 문서간에 "관계"를 만들 때 어떻게 결정합니까?
나는 그것이 훨씬 더 "객체 지향적"일 것이라고 생각하고 다음과 같이 나눈다면 Value Objects에 매핑하기가 더 쉬울 것입니다.
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author_id: "Lance1231"
tags: ["sample", "post"]
}
}
authors {
author {
id: "Lance1231"
name: "Lance"
age: "23"
}
}
comments {
comment {
id: "comment1"
body: "Interesting Post"
post_id: 123412804910820
}
comment {
id: "comment2"
body: "I agree"
post_id: 123412804910820
}
}
...하지만 관계형 데이터베이스처럼 보이기 시작합니다. 그리고 종종 나는 "전체 사이트-내-문서"처럼 보이는 것을 물려 받기 때문에 관계로 모델링하기가 더 어렵습니다.
관계형 데이터베이스와 문서 데이터베이스를 사용하는 방법 /시기에 대해 많은 것을 읽었으므로 여기서는 주요 문제가 아닙니다. CouchDB에서 데이터를 모델링 할 때 적용 할 좋은 규칙 / 원칙이 무엇인지 궁금합니다.
또 다른 예는 XML 파일 / 데이터입니다. 일부 XML 데이터에는 10 개 이상의 수준이 중첩되어 있으며 ActiveRecord, CouchRest 또는 기타 Object Relational Mapper에서 JSON을 렌더링하는 것과 동일한 클라이언트 (예 : Ajax on Rails 또는 Flex)를 사용하여 시각화하고 싶습니다. 때로는 아래처럼 전체 사이트 구조 인 거대한 XML 파일을 얻고 Rails 앱에서 사용하기 위해 Value Objects에 매핑해야하므로 데이터를 직렬화 / 역 직렬화하는 다른 방법을 작성할 필요가 없습니다. :
<pages>
<page>
<subPages>
<subPage>
<images>
<image>
<url/>
</image>
</images>
</subPage>
</subPages>
</page>
</pages>
따라서 일반적인 CouchDB 질문은 다음과 같습니다.
- 문서를 나누는 데 사용하는 규칙 / 원칙 (관계 등)은 무엇입니까?
- 전체 사이트를 하나의 문서에 넣어도 괜찮습니까?
- 그렇다면 임의의 깊이 수준으로 문서를 직렬화 / 역 직렬화하는 방법 (위의 큰 json 예제 또는 xml 예제)을 어떻게 처리합니까?
- 아니면 그것들을 VO로 바꾸지 않습니까? "이것들이 객체-관계형 맵에 너무 중첩되어 있으므로 원시 XML / JSON 메서드를 사용하여 액세스 할 것"이라고 결정합니까?
도와 주셔서 감사합니다. CouchDB로 데이터를 나누는 방법에 대한 문제는 "지금부터 이렇게해야합니다"라고 말하기 어려웠습니다. 곧 도착하기를 바랍니다.
다음 사이트 / 프로젝트를 공부했습니다.
- CouchDB의 계층 적 데이터
- CouchDB 위키
- 소파-CouchDB 앱
- CouchDB 최종 가이드
- PeepCode CouchDB 스크린 캐스트
- 소파 휴식
- CouchDB 읽어보기
... 그러나 그들은 여전히이 질문에 대답하지 않았습니다.