2014-01-20 2 views
0

나는 이러한 목적을 위해 공동 블로그 또는 위키로 간주 될 수있는 웹 응용 프로그램을 보유하고 있습니다. 사람들은 일련의 문서를보고 편집 한 다음 다시 게시하고 특정 문서의 게시 된 버전에 대한 개정 기록을 추적해야합니다. 척도는 수십만 건의 문서가 될 것이고, 각각 10 건의 개정판 (규모의 순서 + 또는 -1)과 수십만 명의 사용자가있을 것이며, 수십 건의 개정 내역에 관심을 가질 것입니다.테이블의 특정 열에 대한 버전을 추적하는 가장 좋은 방법은 무엇입니까?

문서 자체는 간단합니다 (일부 소유권/ACL 및 태그 속성이있는 텍스트 열). 수정 시스템을 처리하는 몇 가지 방법을 생각하고 있습니다. Approach A는 doc 테이블에서 버전 번호를 추적하는 다른 컬럼을 갖는 것입니다. 따라서 문서 ID 1은 버전 1, 2, 3 등을 가질 수 있습니다.이 경우 테이블에는 ID가 아닌 (id, version)에 대한 인덱스가 필요합니다.

질문 : 이것은 나쁜 생각입니까? postgres에 activerecord에서 단일 열 기본 키가없는 문서가있는 것이 가능한지 확실하지 않습니다. 나는 (doc_id, version_id)에 doc_id 열과 인덱스를 가질 수도있다./doc/: id에 대한 내 REST 끝점에 대한 호출은 머리를 반환하고/doc/: id? ver = N은 버전 N을 반환하므로 충분히 강력합니다. 원하는 작업을 멋지게 매핑합니다.

다른 옵션은 별도의 기록 테이블이므로 문서 테이블에 마지막 버전이 포함되어 있으며 그 밖의 모든 기록은 기록에 대한 다른 테이블에 저장됩니다. 그것은 처음에는 유용하지 않은 것 같지만 역사 표 접근법은 (누가이 변화를 만들 었는지) 책임과 다른 데이터를 역사에 관해 저장하도록합니다. 필자는 paper_trail 젬을 보았습니다.이 툴이 많이 사용되었지만 paper_trail은 훨씬 일반적인 범용 케이스로 작성되었습니다. 한 텍스트 컬럼에서 변경 사항을 추적하면됩니다.

그래서 제안 사항이 있습니까? 내 데이터베이스 - 조직 기술은 천천히 속도를 오르고 있으며, 나는 이것이 아주 중요한 실수를 할 수있는 곳이라고 생각합니다.

답변

1

서류 흔적 (https://github.com/airblade/paper_trail)과 비슷한 것을 사용 해본 적이 있습니까? 비슷한 작업을 위해 이전에 사용 했으므로 버전 관리를 좋아합니다.

+0

이 시나리오에서는 유용하지만 어쩌면 과도한 것 같습니다. – pfooti

0

(id, version) 접근법의 문제점은 최신 정보를 얻기가 서투르지 만 비효율적이며, 대부분의 시간을 원하는 것입니다.

이전 버전을 부차적 인 테이블에 저장하는 것이 좋습니다. 버전 번호를 순차적으로 나열하지 마세요. 1, 2, 3, 4; 로 저장하십시오. 제대로 유용한 기본적인 모든 종류의 지원을 거부 끔찍한 의견을 고집 ORM이 액티브를 사용하고 또한

SELECT row_number() OVER (ORDER BY version_created_time), 
     version_text 
FROM versions; 

: 그것을 표시 할 때 버전 번호 시리즈를하려면 row_number() 윈도우 함수, 예를 사용 자연 복합 키와 같은 관계형 데이터베이스 기능 그렇게하기 위해 노력하는 것은 고통의 세계 일 수 있습니다.

관련 문제