2013-01-19 3 views
0

다운로드 사이트와 같은 데이터베이스를 설계해야합니다. 나는 사용자, 각 사용자가 다운로드 한 프로그램을 추적하고 또한 사용자가 프로그램을 평가하고 의견을 달 수 있도록하고 싶다.이 데이터베이스에서 필요한 것들 - 프로그램에 대한 평균 평점을 얻고, 프로그램에 대한 모든 의견을 얻고, 어떤 프로그램을 정확히 알고 있는지 (각 프로그램이 몇 번 다운로드되었는지는 신경 쓰지 않지만 각 사용자가 다운로드 한 프로그램을 알고 싶다.) 각 프로그램에 대한 의견 수와 그 프로그램에 대한 의견 수를 계산할 수도 있습니다.사용자를위한 데이터베이스 설계 다운로드

사용자 (UID, UNAME 등)

프로그램 (PID - 나는 간단한 유지하려는 개인 사용) 나는이 단체로 와서 , PNAME)

다음 relationships-

UserDownloadedProgram (UID, PID, 타임 스탬프)

UserCommentedOnProgram (UID, PID, commentText, 타임 스탬프)

UserRatedProgram

(uid, pid, rating)

내가이 방법으로 선택한 이유 - 관계 배송 (사용자 다운로드, 사용자 의견 및 요율)은 수없이 많습니다. 사용자가 많은 프로그램을 다운로드하고 많은 사용자가 프로그램을 다운로드합니다. 댓글에 대해서도 마찬가지입니다 (많은 프로그램에 대한 사용자 의견 및 많은 사용자가 프로그램에 댓글을 달거나 평가 함). 내가 아는 가장 좋은 방법은 일대 다 (관계 테이블) 인 세 번째 테이블을 만드는 것입니다. . 이 디자인에서 평균 평점 및 주석 검색은 조인 쿼리 또는 비슷한 것으로 가정합니다. 저는 데이터베이스 디자인에서 멍청한 놈입니다.하지만 모범 사례를 고수하려고했는데,이 디자인이 다소 좋아 졌습니까? 아니면 뭔가를 간과하고 있습니까?

다른 가능성을 분명히 생각할 수 있습니다. 어쩌면 주석 및 등급은 엔티티 (테이블) 일 수 있으며 관계는 3 개의 엔티티 사이에 있습니다. 난 그게 어떤 장점/단점인지 정말 모르겠다 : 나는 정말로 코멘트 나 등급에 관심이 없다는 것을 안다. 나는 단지 적절한 곳에 표시하고 유지하고 싶다. (필요할 때 지워야한다.) 그래서 어떻게하면 좋을까? 그들이 실체가되는 것이 더 나은지 나는 압니까?

의견이 있으십니까?

+0

Eww 열의 접두사를 사용하지 마십시오. 나는 이것을 볼 때마다 울다. 사용자 테이블의 Id 열은 분명히 사용자 ID이므로 uid로 호출 할 필요가 없습니다. 사용자 테이블을 참조하는 다른 테이블에서 - 열은 UserId라고해야합니다. – Milney

답변

0

rules of normalization에 지정된대로 새 항목을 만듭니다. 주석을 추가로 (별도의) 표를 만들 특별한 이유는 이미 있으므로 주석이 있습니다. 댓글을 작성한 사람과 적용한 댓글의 프로그램은 댓글의 본질적인 속성입니다. 이러한 관계를 나타내는 외래 키 (주석 테이블의 관점에서 다 대일)는 사용자가 입력 한 위치에 속합니다.

제안한 표는 모범 사례에 따라 허용되는 세 번째 정규 서식 인 입니다. 귀하가 거래 기반으로 데이터를 추적하고있는 것처럼 보입니다 (즉, 발생하는 이벤트를 기록하는 등). 이는 훌륭한 정보이기 때문에 원하는 것을 언제든지 파악할 수 있기 때문에 좋은 연습입니다.

다운로드 수 또는 댓글 수를 계산하는 것은 SQL Aggregate Functions에 검색어에 적용되는 외래 키 (예 : where pid=1234

0

고유 한 ID를 가진 다운로드 용 엔티티를 작성합니다. 당신은 다운로드 상태를 가질 수 있습니다, 당신은 한 사용자에 대해 동일한 프로그램을 여러 번 다운로드 할 수 있습니다. 다운로드를 주문이나 다른 것으로 연결해야 할 수도 있습니다.