많은 웹 사이트에서
에 게시물이 마음에 들었거나 싫어하는 옵션이 있습니다.
여기에서도 물론 stackoverflow에서.데이터베이스 디자인 : 좋아하는 테이블?
이렇게 기술적으로 큰 좋아하는 테이블입니까?
user_id post_id
USER_ID -
post_id를 투표 - 그것은
에게 있습니다 포스트는 모든에 대해 무엇입니까?
큰 좋아하는 테이블?
더 효율적이거나 정교한 무언가가 없습니까?
가장 기본적인 수준입니다. 네, 그게 전부입니다.
하지만 다음과 같은 질문에 대답하기 위해 노력하고, 확장하기 시작 :
이 그럼 당신은 친구와 지역 사회에 대한 깊이 질문에 더 대답 할 시작 후 같이한다.
귀하의 우려를 이해할 수 있다고 생각합니다. 페이지를 제시 할 때마다 COUNT()를 발행해야합니다.
이 기본 테이블은 COUNT()의 기초가 될 수 있지만 꼭 액세스 할 때마다 COUNT (개)하지 않아도됩니다.
총계 테이블을 생성하고 페이지가 비슷하거나 싫어하거나 트리거를 사용하거나 저장된 프로 시저를 호출하여 수시로 업데이트 할 때 업데이트하십시오.
나는 각 방법이 다른 사이트 개성, 즉 더 많은 독서 또는 더 많은 글에 대해 더 많이 언급되었지만, 좋아하거나 싫어하는 것에 관해서는 아무것도 알 수 없다는 것을 이미 알고있다.
그래서 실질적으로 내가 좋아할 수있는 게시 테이블이 있다고 가정합니다. COUNT()를 사용할 필요가 없도록 좋아요 수를 세는 필드 "likes_counter"가 있어야합니다. 권리? – socksocket
수정. 목표 테이블을 사용하여 컬럼을 추가하면 서버에 여분의 테이블을 저장하는 접근 방식입니다. 목표 테이블의 구조를 변경하는 것이 허용되면 좋습니다. 그렇지 않은 경우 targetTableName, totalLikes라는 두 개의 열을 포함하는 별도의 테이블을 만듭니다. DB에 대한 모든 권한이 있다고 가정 해 보겠습니다. 내 고려 사항은 단순하게 다른 디자인 대안에주의를 환기시키는 것이었다. –
어떤 기준에서 큰 테이블이라고 생각하십니까? –
게시물을 좋아하거나 싫어하는 사람에 대한 정보를 보관해야하는 경우 저장할 필요가있는 최소한의 데이터입니다. – JJJ