협업 아티클 편집기의 테이블 구조가 좋음

Question

관리자가 기사를 업로드하고이를 편집하기 위해 많은 사용자와 공유 할 수있는 앱이 있습니다. 기사는 MySQL DB에 개별 행으로 저장되는 문장으로 나뉩니다. 각 사용자는 한 번에 하나씩 기사 문장을 편집 할 수 있습니다. 관리자가 기사 문장 (병합, 이동, 삭제, 편집, 추가)을 조정하고 기사 문장과의 사용자 관계의 무결성을 유지할 수 있도록 관리자가 데이터베이스를 구성하는 방법은 무엇입니까? 다음은 기본 구조입니다 : 내가 볼

article_sentences 
--------------- 
-id (auto_increment) 
-article_id (FK) 
-paragraph_id 
-content 

user_article_sentences 
--------------- 
-user_id (FK) 
-article_id (FK) 
-article_sentence_id (FK) 
-user_content 

하나의 문제는 article_sentence의 ID의 변화이다. 관리자가 기사를 이동하면 기사 내용이 올바른 순서로 표시되도록하려면 ID가 변경되어 paragraph_id가 변경 될 수 있습니다. 이를 해결하기 위해 article_sentence_order 열을 추가 할 수 있습니까? 그런 식으로 ID는 변경되지 않지만 내용의 순서는 article_sentence_order 열에 의해 결정됩니다.

병합 및 삭제는 어떻게됩니까? 서로 다른 ID의 단편화가 발생하기 때문에 이러한 문제가 발생할 수 있습니다.

이러한 문제를 해결하는 데 도움이되는 새로운 스키마 디자인에 대한 아이디어가 있습니까? Google 문서 도구와 같은 앱이 이러한 유형의 문제를 어떻게 처리합니까?

편집 :

은 주위에 다른 문장을 이동하는 문제를 해결하기 위해. order_id라는 새 열을 사용할 수 있으며 varchar 또는 int 일 수 있습니다. 일부 절충 사항 : int 인 경우 다음 문장의 order_id를 1만큼 증가시켜야합니다. varchar를 사용하는 경우 order_id는 3과 4 사이에 삽입하려면 '3a'와 같을 수 있습니다.이 문제는 내 응용 프로그램 코드에서 숫자 인덱스를 사용하여 다음 문장과 이전 문장으로 이동하는 것이 문제.

다른 대안이 있습니까?

Answer 1

각 레코드의 버전 번호가 포함 된 전체 버전의 컨텐츠 만 보관하면 편집 된 기사의 전체 기록을 볼 수 있으며 수정 된 사람은 누구입니까?

User: 

- id 
- name 

User_article: 

- id 
- user_id (fk on user, this is the current editor) 
- article_id 
- version_number 
- article_content (the full content of the article) 

Article: 

- id 
- created_date 
- user_id (the creator, or main owner) 
- category_id 

이 방법은 등,

수정 만들 었는지 어떤 사용자 확인, 역사에서 이전 시점에 내용의 기사를 복귀하는 것은 매우 쉽습니다