2008-11-04 3 views
1

나는 사이드 프로젝트를위한 데이터베이스 스키마를 디자인하려고 노력했지만, 내가 편한 어떤 것도 만들 수 없었다. 내 데이터 액세스를 위해 LINQ와 함께 ASP.Net을 사용하고 있습니다.동적 항목에 관한 데이터베이스 디자인 - 한 행 또는 여러 행?

사용자는 2 개의 숫자 속성과 1 개의 참조 속성 인 항목 이름으로 최대 10 개의 "항목"을 지정할 수 있습니다.

이 항목을 1 행에 입력하면 30 개 이상의 열 (최소)과 쉽게 동일 할 것입니다. 는 item_1_name (REF) 는 item_1_volume item_2_name ... 등 ...

을 item_1_weight 그리고 각 속성은 기본적으로 1에서 400 + 범위 수 단순히 참조 테이블에 이러한 열을 켤 수 없습니다.

사용자가 항목에 항목 1 개를 넣기로 결정한 경우 해당 데이터에 대한 개체를 만드는 방법은 LINQ처럼 고정적 일 것이라고 생각했습니다. 속성 및 기타 등등이 있는지 확인해야합니다. NULL을 지정하고 그에 따라 작업하십시오. 또한 항목에 허용되는 항목의 수를 늘리고 싶다면 두통이 될 수 있습니다.

내가 생각해 본 다른 옵션은 각 항목에 대한 행을 만들고이를 항목 ID와 연결하는 것입니다. 그래서 나는 본질적으로 널 엔트리를 가지지 않을 것이지만, 내 테이블은 천문학적으로 깊지 만 아주 넓지는 않을 것입니다. 단지 5 개의 홀수 열만 있기 때문입니다.

내 디자인에서 간과 할 부분이 있습니까?/이렇게하는 것이 훨씬 효율적이고 효율적인 방법이 있습니까?

EDIT : 내가 천문학적으로 성장할 것이라고 말할 때, 사용자가 항목을 만들 수 있고 각 항목에 항목 그룹이있을 가능성이 높습니다. 따라서 사이트에서 하루에 1 회 항목을 만들면 항목의 최대 개수 (10)와 함께 항목의 그룹 3 개를 가질 수 있습니다.이 항목의 유일한 항목은 30 개입니다. 이 비율로 매일 1 주일 동안 항목을 작성하면 단일 사용자에 대해210 개의 행을 가질 수 있습니다.

답변

2

나는, 당신이 언급 후자의 디자인을 추천 다섯 개의 열 하나 개의 종속 테이블을 만들 것입니다 : 나는 숫자를 포함 위의 표 num_items을 보여

CREATE TABLE Items (
    user_id    INTEGER NOT NULL, 
    item_id    INTEGER NOT NULL DEFAULT 1, 
    numeric_property1  INTEGER, 
    numeric_property2  INTEGER, 
    referential_property INTEGER, 
    PRIMARY KEY (user_id, item_id), 
    FOREIGN KEY (user_id) REFERENCES Users(user_id) 
         ON DELETE CASCADE, 
    FOREIGN KEY (item_id) REFERENCES num_items(item_id), 
    FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column) 
); 

(1) 대부분에서 10 개 항목에 사용자를 제한하려는 경우 (10)를 통해이 디자인의

CREATE TABLE num_items (item_id INTEGER NOT NULL); 
INSERT INTO num_items (item_id) 
    VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10); 

장점이 COUNT()에 지정된 사용자가 얼마나 많은 항목을 쉽게한다는 것입니다, 그것은 MIN()과 같은 것들을 계산하기 쉽게 특정 속성에 대해 MAX() 인 경우 참조 속성에 대해 외래 키를 적용 할 수 있습니다.

일부 데이터베이스는 자동 증가 등 복합 기본 키 (이 경우 item_id)의 두 번째 부분을 선언하는 기능이 있습니다, 그래서 당신은 entity_id에 대한 값을 지정하고 item_id를 생략하면 자동으로 다음 사용되지 않는 값을 가져옵니다 (그러나 하나를 삭제하면 간격을 채우지 않습니다.) 어떤 브랜드의 데이터베이스를 사용하고 있는지 알려주지 않으므로이 기능을 이해할 수 있도록 남겨 두겠습니다.

편집 : Tony Andrews가 답변 한대로 행 수는 문제가되지 않습니다. 어떤 데이터베이스 브랜드를 사용할지 명시하지 않지만 MS Access와 같이 특히 약한 제품을 선택하지 않으면 데이터베이스를 사용하여 수백만 행을 쉽게 처리 할 수 ​​있습니다. 인덱스를 잘 선택하고 해당 인덱스를 사용하는 쿼리를 작성하면 효율성이 문제가되지 않습니다.

+0

외래 키 대신 item_id에 CHECK 제약 조건을 사용하는 것이 더 좋지 않습니까? – Dave

+0

내 편집을 확인하십시오. 나는 동의한다, 그러나 나는 열의 수가 거대하게 될 것이므로 내가 할 일의 효율성에 여전히 관심이있다. – MunkiPhD

+0

예, CHECK 제약 조건을 사용할 수 있지만 12 개 항목으로 확장해야하는 경우 CHECK 제약 조건을 수정하면 메타 데이터가 변경되므로 (ALTER TABLE) 비용이 많이 듭니다. 값 (11), (12) 삽입은 쉬운 데이터 변경입니다. –

0

단일 항목 테이블 사용 : 널 (null),

userId를, itemIndex라는 isReference, numericValue, 만일 ReferenceValue 진정한 사용자 999 item_3_name의 값이

999,3로 변환

이런 식으로, 값

사용자는 특정 제약 조건을 적용해야합니다. 사용자 당 항목의 최대 번호 등

+0

확장 성과 참조 무결성에 많은 문제가있는 EAV 설계에 대해 설명하고 있습니다. 예를 들어, 참조 속성에 외래 키를 선언하는 방법은 무엇입니까? –

0

적절한 데이터베이스 디자인은 각 사용자/항목을 별도의 행에 저장하는 것입니다. 이렇게하면 작업하기가 훨씬 쉬워지고 10 개 항목의 임의 제한을 제거합니다. 나는 그것이 "천문학적으로 깊은"성장할 것이라고 말하지 않을 것이고, 약 10 x (사용자 수 없음)의 행이있을 것입니다.