우리는 현재 gumtree와 비슷한 구매 및 판매 사람들을위한 온라인 광고 사이트를 개발하고 있습니다. 이는 회사에서 근무하는 직원에게 사용된다는 것이고, 회사 외부에서 오는 사람들에게는 접근 할 수 없다는 것입니다. 회사.SQL Server 2008의 테이블 분할
이제 하위 카테고리가있는 15 개의 카테고리와 하위 카테고리에 하위 카테고리가 있습니다.
우리는 대신에 구성되어 하나 개의 거대한 테이블을 가지고 지금 등 항목 Id, 제목, 부제목, 설명, CreatedBy, BroughtBy, STARTDATE, 종료 날짜 및 ParentCategoryId, SubCategoryId 및 ChildCategoryId에을 구성 광고라는 기본 테이블이 그들이 판매하는 품목에 대한 모든 세부 사항은 항목의 세부 사항에 대해 카테고리 당 별도의 표를 만들려고했다.
그래서 우리는 그들이 (주 고라 테이블에 FK가 될 것이다) 즉 항목 Id, 메이크업, 모델, 색상, 운수성, 세금 등
판매 된 자동차에 대한 모든 세부 사항을 것이다 Advert.Vehicle_Spec있을 것입니다그런 식으로 우리가 메인 테이블 Advert를 쿼리 할 때 우리는 관련 스펙 테이블에 가입 할 수 있습니다. 어떤 식 으로든 테이블을 깨끗하고 단정하게 유지할 수있게되었습니다. 이제 내 질문이 당신에게 좋은 접근 방법이 될 것입니까? 이 접근 방식에 성능 문제가 있습니까? 쿼리와 관련하여 필요한 모든 관련 FK를 만들 것입니다.
이 질문은 SQL Server 포럼에서 한 번씩 물어 보았습니다. 각 카테고리는 XML 스키마를 가져오고 XML 태그와 값이 유지됩니다 하나의 필드에 있지만 데이터는 판매되는 품목의 유형에 따라 다릅니다. 이것은 더 많은 셋업을 필요로하지만 성능과 유연성의 전반적인 균형이 가장 좋을 것입니다. 개인적으로 SQL 내에서 XML로 작업 한 적은 없기 때문에 좋은 접근 방식인지 아닌지에 대해 논평 할 수 없습니까?
각 카테고리에는 여러 상태가있을 수 있습니다. 각 상태에 대한 설명을 보유하고있는 다양한 테이블을 이미 보유하고 있으며, 우리가 수행 할 쿼리는 선택, 삭제, 삽입, 업데이트에 따라 다릅니다. 일부 쿼리에는 여러 조인이 있습니다. 상태/사용자 테이블에서 우리는 검색 대상에 따라 사용자에게 제안 된 모든 레코드를 보여주는 "제안"양식을 구현할 것입니다.
유연성과 성능면에서 XML이 적절한가요?
이 접근법의 유일한 고려 사항은 외래 키 제약 조건 및 무결성에 대해 신중하게 고려해야 할 필요가 있다는 것입니다. XML 내에서 외래 키 제약 조건을 적용 할 수 있다고 생각하지 않습니다. –
Scott은 예를 들어 ItemID를 공통 열로 지정했습니다. 그런 다음 내부 조인을 사용하여 동일한 조건의 하위 테이블을 쿼리 할 수 있습니다. 문제는 XML PATH/XML AUTO 등을 사용하는 것 이상입니다. XSLT를 사용하는 테이블에서. –
@LebronJames 늦은 답장을 드려 죄송합니다. DB에이 정보를 저장하는 올바른 방법 인 것 같습니다. 어떻게 구조화 할 수 있습니까? 즉 데이터 유형 등이 XML 값을 보유하는 하나의 열에 의해 Adverts 테이블을 확장해야합니까? 나는 이것을 발견했지만, 이것이 당신의 이야기에 관한 것인지 확실하지 않습니다. http://msdn.microsoft.com/en-us/library/ms176009.aspx –