2013-10-14 3 views
0

사용자가 페이지를 구독 할 수있는 페이지 가입 형 응용 프로그램이 있습니다. 페이지를 볼 때 구독 한 사용자 수와 사용자 목록을 모두 표시하려고합니다.페이지 서브 스크립 션 테이블 스키마

또한 사용자 프로필을 볼 때 사용자가 구독하는 모든 페이지가 표시되어야합니다.

내가 생각하는 것은 이것이다 :

Page 
    id 
    users (JSON format containing userIDs of all subscribed) 

User 
    id 
    page_IDs (JSON format containing the IDs of the walls he is subscribed to) 

나는 이것이 매우 작은 규모의 애플리케이션을위한 괜찮 같아요. 그러나 사이트가 성장하고 각 페이지 당 1000 명 이상의 가입자가있는 경우 모든 JSON 데이터를 PHP로 배열로 디코딩하는 것은 좋은 생각이 아닙니다.

더 나은 스키마를 염두에 둔 사람이 있습니까?

고마워요!

+0

이 –

+0

좋아 ... 그냥이 이것에 대해 물어 좋은 아이디어라고 가정 해 봅시다 : 상황에보다 구체적인

? 그래서...? 하하 .. 도움이 필요해? –

+0

죄송합니다. 그 의견을 쓸 때 답변을 게시 할 시간이 없었습니다. 이제 나는 하나 추가 : –

답변

0

그럼 디자인이 좋지 않습니다. 그것은 실제로 나쁘다. 원칙적으로 목표는 전체 채우기 , 최소, first normal form 인 스키마를 갖는 것입니다.

페이지에 여러 명의 사용자가 가입 할 수 있고 사용자가 여러 페이지에 가입 할 수 있습니다. 테이블 users과 테이블 pages 사이에는 다 대다 관계가 있습니다.

이러한 상황에서 가장 좋은 해결책은 둘 사이의 연결을 만드는 세 번째 테이블을 만드는 것입니다. 1 외래 키 일명 표 1에서 기본 키를 포함

  • 열 (2)에 대한 예외가 있습니다

외래 키 일명 표 2에서 기본 키를 포함 : 일반적으로이 테이블은 2 열로 구성 하지만 일반적으로 이것은 이와 비슷한 것을 디자인/정규화하는 방법입니다.

pages 
------------------------- 
page_id 
<other columns> 
PRIMARY KEY(page_id) 

users 
------------------------- 
user_id 
<other columns> 
PRIMARY KEY(page_id) 

subscriptions 
------------------------- 
page_id 
user_id 
PRIMARY KEY(page_id,user_id) 
+0

고마워! 나는 이것을 실제로 생각했다. 그러나이 세 번째 테이블에 많은 레코드가 없을 것입니까? –

+0

@AninditKarmakar 예,있을 가능성이 큽니다. 그러나 열이 인덱싱되고 정수인 경우 (ID이므로 확인 됨) 공간이나 성능 문제가 발생하지 않습니다. RDBMS는 모든 상황에서 효율적으로 작동하도록 구축되고 최적화됩니다. 우리가 수억 개의 행에 대해서 이야기하지 않는다면 (그리고 나는 우리가 그렇게 생각하지 않는다) 괜찮을 것이다. –

+0

아 맞다! 예, 색인이 생성됩니다. 고마워! –

관련 문제