2012-04-21 4 views
0

사용자가 제품에 대한 의견을 남길 수있는 상점 웹 사이트가 있다고 가정합니다.데이터베이스 구조, 여러 엔터티에 대한 하나의 큰 엔터티

내 웹 사이트 데이터베이스에 테이블 (엔티티)이 있다고 가정하면 '신발', '모자'및 '스케이트'가됩니다. 모든 항목 (예 : 'shoes_comments', 'hats_comments', 'skates_comments')에 대해 별도의 '주석'테이블을 만들고 싶지 않습니다. 제 생각은 어떻게 든 모든 주석을 하나의 큰 테이블에 저장하는 것입니다. 의견이 수있는 모든 개체에 대한

table (comments): 
ID (int, Primary Key), 
comment (text), 
Product_id (int), 
isSkates (boolean), 
isShoes (boolean), 
isHats (boolean) 

과 같은 플래그 :이 작업을 수행하는

한 가지 방법은, 내가 생각하는 것이, 테이블을 만드는 것입니다.

그럼이 SELECT 쿼리의 모습 일부 제품에 대한 의견 싶어 때

SELECT comment 
FROM comments, ___SOMETABLE___ 
WHERE ____SOMEFLAG____ = TRUE 
    AND ___SOMETABLE___.ID = comments.Product_id 

이 필요한 기능에 대한 데이터베이스를 구현하는 효율적인 방법입니다? 내가 할 수있는 다른 방법은 무엇입니까?>

답변

1

주석에 대해 하나의 테이블을 만들고 주석 테이블에 다른 테이블의 외래 키를 사용하는 것이 좋습니다.

+0

제 아이디어는 다소 다릅니다. 난 당신의 생각을 이해 : 모든 엔터티 테이블에 대한 글로벌 댓글 테이블에 외래 키를 추가합니다. –

1

죄송합니다. 이상하게 느껴집니다.

실제로 각 제품 유형마다 별도의 표가 있습니까? 공통 필드 (예 : 이름, 설명, 가격, 제품 이미지 등)가 없습니까? 모자 제품 라인에 특정 필드 만에 product에 외래 키와 일반 필드 product, comments하지만 hasX 열, hat : 테이블로

나의 추천. hat의 기본 키는 product PK이거나 개별 고유 값입니다 (외래 키에 대한 추가 필드가 product이어야합니다).

+0

좋아, 내가 한 종류의 제품에 대한 것 같아요, 이것은 어려운 하나되지 않습니다. 하지만 내 상황에서 나는 완전히 별개의 것들 (가정 : 조직, 직원, 기술 장비)의 엔티티가 나는 그들을 위해 의견을 저장할 필요가 ... –

+0

그래, 나는 너의 모범에 대해 오도했다. 미안하다. 그래도 규칙을 약간 굽히려한다면 '주석'테이블 하나만 있으면됩니다. 내가 생각하는 각각의 엔티티에 대해'comment'에 외래 키 컬럼을 갖고 싶지 않습니다. 실제 외래 키 컬럼은 없지만'comment'에'parent_id'로 선언 된 컬럼이 있다면? 나는 'X'에서 'comment'까지의 관계가 단방향 일 수 있다고 생각하니? 하나의 대안은 각각의'X '에 대한''comment'에 대한 조인 테이블을 'shoe_x_comment','hat_x_comment'와 같이하는 것입니다. –

0

이 작업을 수행하는 "정규화"방법은 또 하나의 엔티티를 추가하는 것입니다 (예를 들어, "제품") 그 (댓글 포함) 신발, 모자와 스케이트 성능 고려 사항 외에

   +-- 0..1 [Shoe] 
       | 
[Product] 1 --+-- 0..1 [Hat] 
    1   | 
    |   +-- 0..1 [Skate] 
    * 
[Comment] 

에 공통 그룹의 모든 특성 여기서 단점은 데이터 모델에서 Shoe의 행과 Hat의 행 모두에서 Product의 행을 참조하지 못하도록하는 것입니다.

다른 대안들도 있습니다 (각각은 &의 결함이 있음) - "jp 상속 전략"에 대해 읽고 싶을 수도 있습니다 - 당신은 같은 주제를 다루는 자바 관련 기사를 찾을 것입니다 (그냥 자바를 무시하고 나머지 읽기)

개인적으로, 나는 계층 구조 (우리의 경우 신발, 모자, 스케이트)의 모든 엔티티에 대해 단일 테이블을 사용하고 성능 및 단순성의 제단에 대한 제약 조건을 희생하는 경우가 종종 있습니다. 구두는 필수이지만 모자와 스케이트는 필수가 아닌 분야).

+0

내가 "COMMENTABLE"테이블을 만들고 엔터티 테이블 (모자, 신발, 스케이트)에서 1 : 1 관계로 연결하는 상황에서이 작업이 가능합니까? –

+0

그래, 그게 좋은 생각이야! 그것을하기 전에, 당신은 공연을 고려하고 싶을 것입니다. 예를 들면 : 새로운 신발을 추가하기 위해서는 두 개의 삽입 문이 필요합니다 (Commentable에 1, Shoe에 1) - 당신이 코멘트의 ID를 가지고 있고 싶으면 그 엔티티 엔티티로 이동하면 엔티티가 어떤 테이블 (구두, 모자 또는 스케이트일지도 모른다)에서 미리 알지 못하는 것처럼 (아마도 여러 개의) 노조 조항이 필요할 것입니다 ... – giorgiga

+0

여기의 문제는 실제로 E/R은 상속을하지 않습니다. (JPA의 3 가지 전략과 같이) 그것을 시뮬 레이팅 할 수는 있지만 약간의 트레이드 오프를 받아 들여야합니다 – giorgiga

관련 문제