3

저는 사용자가 판매하는 품목의 유형별 세부 정보가 포함 된 분류 된 광고를 게시 할 수있는 웹 사이트를 프로그래밍하고 있습니다. 그러나 최고의 데이터베이스 스키마에 대한 질문이 있습니다.단일 상속 또는 다형성?

사이트에는 많은 카테고리 (예 : 자동차, 컴퓨터, 카메라)가 있으며 광고의 각 카테고리에는 고유 한 필드가 있습니다. 예를 들어, 자동차에는 문 개수, 제조사, 모델 및 마력과 같은 속성이 있지만 컴퓨터에는 CPU, RAM, 마더 보드 모델 등과 같은 속성이 있습니다.

이제는 모두 목록이므로 다형성 접근 방식을 사용하여 각 카테고리 (COMPUTERS, CARS, CAMERAS)별로 상위 LISTINGS 테이블과 다른 하위 테이블을 만듭니다. 각 하위 테이블에는 LISTINGS TABLE으로 다시 링크되는 listing_id가 있습니다. 따라서 목록을 가져 오면 연관된 하위 테이블의 연결된 행에 의해 조인 된 LISTTINGS에서 행을 가져옵니다.

LISTINGS 
-listing_id 
-user_id 
-email_address 
-date_created 
-description 

CARS 
-car_id 
-listing_id 
-make 
-model 
-num_doors 
-horsepower 

COMPUTERS 
-computer_id 
-listing_id 
-cpu 
-ram 
-motherboard_model 

이제이 스키마는 좋은 디자인 패턴입니까, 아니면 더 좋은 방법이 있습니까?

나는 하나의 상속을 고려했으나 테이블이 너무 빨리 커지기 때문에 생각을 신속하게 없애 버렸지 만 또 다른 딜레마가 떠 올랐습니다. 사용자가 모든 목록에 대한 전체 검색을 수행한다면 그럴 것입니다. 각 하위 테이블을 개별적으로 쿼리합니다. 100 개 이상의 카테고리가 있다면 어떻게 될까요? 비효율적이지 않습니까?

각 카테고리의 필드를 정의하는 마스터 테이블 (메타 테이블)과 각 목록의 필드 값을 저장하는 필드 테이블이 있지만 데이터베이스 정규화와 반대되는 다른 접근법을 생각해 보았습니다.

Kijiji와 같은 사이트는 어떻게합니까?

답변

2

데이터베이스 디자인이 정상입니다. 당신이 가진 것을 바꿀 이유가 없습니다. 검색이 몇 가지 방법으로 수행 된 것을 보았습니다. 하나는 검색 저장 프로 시저가 검색해야 할 모든 테이블을 조인하고 검색 할 열을 색인화하는 것입니다. 필자가 잘 수행 한 두 번째 방법은 검색 할 필요가있는 필드의 복사본을 가져 오는 검색에만 사용되는 테이블을 만드는 것입니다. 그런 다음 해당 필드에 트리거를 넣고 검색 테이블을 업데이트합니다.

두 가지 모두 단점이 있지만 처음부터 두 번째까지 선호합니다.

수정

다음 표가 필요합니다.

카테고리 - 아이디 - 당신이 검색하는 동안 지정된 카테고리에 대한 모든 목록을 가입 할 수 있습니다이 상호 참조 모델 ListingId

- 설명

CategoriesListingsXref - 카테고리 ID . 그런 다음 약간의 동적 SQL (이해하기 쉽기 때문에)을 추가하고 검색하려는 필드를 포함하도록 쿼리를 작성하고 쿼리에서 execute를 호출하십시오.

그게 전부입니다.

EDIT 2 이것은이 메모 상자에서 지탱할 수있는 조금 더 큰 논의 인 것 같습니다. 그러나 우리가 논의 할 내용은 다음 게시물을 읽음으로써 이해할 수 있습니다. http://www.sommarskog.se/dyn-search-2008.html

정말 완벽하고 프로와 단점으로 그것을하는 방법이 하나 이상을 보여줍니다. 행운을 비네.

+0

다른 속성이있는 CARS 테이블과 COMPUTERS 테이블을 함께 결합하는 방법은 무엇입니까? – peter

+0

범주 테이블이 필요합니다. 목록 카테고리에 대한 상호 참조 테이블이 있어야합니다. 그런 다음 사용자는 검색 중에 카테고리를 선택합니다. category_id를 search_stored_proc에 전달하면 category_id를 사용하는 categories-xref 테이블을 통해 검색 할 필드와 조인합니다. 내가 여기서 건너 갈 수없는 몇 가지 세부 사항이있다. 원래 응답을 수정해야 할 수도 있습니다. 그러나 이것이 당신이 따라야 할 개념입니다. – phillip

+0

또는 동적 SQL을 사용하여 검색 쿼리를 빌드하고 호출 할 수 있습니다. 훌륭한 접근법이기도합니다. 가이드 방법은이 게시물을 참조하십시오. http://www.sqlteam.com/article/introduction-to-dynamic-sql-part-1 – phillip

0

내가 선택한 디자인이 방금 설명한 시나리오에 좋을 것이라고 생각합니다. 하위 클래스 테이블에 자체 ID가 있어야하는지 잘 모르겠지만. CAR은 리스팅이기 때문에 값이 동일한 "도메인"에서 나온 것임을 알 수 있습니다.

일반적인 분류 된 광고 사이트에서 광고 데이터는 한 번 기록 된 다음 기본적으로 읽기 전용입니다. 이 도구를 악용하여 사용자가 검색하기 원하는 방식으로 검색하기에 더 최적화 된 두 번째 테이블 집합에 데이터를 저장할 수 있습니다. 또한 검색 문제는 "일반"검색에만 실제로 존재합니다. 사용자가 특정 유형의 광고를 선택하면 고급 검색 (RAM> 4GB, cpu = overpowered)을 수행하기 위해 하위 클래스 테이블로 전환 할 수 있습니다.

관련 문제