데이터베이스에 다양한 유형의 제품 정보를 저장한다고 가정 해 봅시다. 그러나 이러한 제품에는 다른 사양이 있습니다.관계형 데이터베이스에 대한 정보를 확장하는 가장 좋은 방법
우리의 열에서 각 사양을 저장할 테이블 및 모든 제품 (유형에 관계없이)은 서로 다른 ID를 가져야합니다.
는 지금은 하나 개의 일반 테이블을 사양 및 제품의 각 유형 (ProductsPhones,
ProductsTV ...) 하나 개의 하위 테이블 (자동 증가 ID로)
Products 이름과 교장와 연결 한 것을 준수하기 외래 키.
Products 테이블에는 자동 증가 ID가 있으므로이 솔루션은 비효율적입니다.
관계형 데이터베이스를 사용하여이 문제를 해결하는 더 좋은 방법이 있는지 알고 싶습니다.
짧은 대답은 아니오입니다. 관계형 모델은 일차 논리 모델이며, 술어는 엔티티에 따라 다르지만 다른 술어에는 다를 수 없음을의 L합니다. 이는 종속 유형 및 EAV 모델이 지원되지 않음을 의미합니다.
EAV 모델은 SQL 데이터베이스에서 사용할 수 있지만 EAV 행의 값 필드 도메인은 특성 필드의 값에 따라 달라지기 때문에 관계형으로 한정되지 않습니다. 또한 때로는 엔터티 필드의 값에 따라 잘). 실제로 EAV 모델은 질의와 유지 관리에 비효율적 인 경향이 있습니다.
PostgreSQL은 공통 상위 유형 테이블없이 고유 한 자동 증가 ID를 보장 할 수있는 공유 순서를 지원합니다. 그러나 슈퍼 유형 테이블은 여전히 FK 제약 조건에 대한 좋은 아이디어 일 수 있습니다.
당신은 같은 공통 속성을 유지하기 위해 나중에Products 테이블에 대한 몇 가지 사용을 찾을 수 있습니다
Type, Serial number, Cost, Warranty duration, Number in stock, Warehouse, Supplier, 등등 ... 제품 테이블을 갖는 것은 괜찮
이 작업은 완전히 관계형 일 수는 없지만 테이블을 일부 표준화하고 코드 작성을 좀 더 쉽게 할 수 있습니다. Phone (전화)에 대한 그래서
-- what are the products?
Products (Id, ProductTypeId, Name)
-- what kind of product is it?
ProductTypes (Id, Name)
-- what attributes can a product have?
Attributes (Id, Name, ValueType)
-- what are the attributes that come with a specific product type?
ProductTypeAttributes (Id, ProductTypeId, AttributeId)
-- what are the values of the attributes for each product?
ProductAttributes (ProductId, ProductTypeAttributeId, Value)
및 TV :
이러한 테이블을 가질 수
ProductTypes (1, Phone) -- a phone type of product
ProductTypes (2, TV) -- a tv type of product
Attributes (1, ScreenSize, integer) -- how big is the screen
Attributes (2, Has4G, boolean) -- does it get 4g?
Attributes (3, HasCoaxInput, boolean) -- does it have an input for coaxial cable?
ProductTypeAttributes (1, 1, 1) -- a phone has a screen size
ProductTypeAttributes (2, 1, 2) -- a phone can have 4g
-- a phone does not have coaxial input
ProductTypeAttributes (3, 2, 1) -- a tv has a screen size
ProductTypeAttributes (4, 2, 3) -- a tv can have coaxial input
-- a tv does not have 4g (simple example)
Products (1, 1, CoolPhone) -- product 1 is a phone called coolphone
Products (2, 1, AwesomePhone) -- prod 2 is a phone called awesomephone
Products (3, 2, CoolTV) -- prod 3 is a tv called cooltv
Products (4, 2, AwesomeTV) -- prod 4 is a tv called awesometv
ProductAttributes (1, 1, 6) -- coolphone has a 6 inch screen
ProductAttributes (1, 2, True) -- coolphone has 4g
ProductAttributes (2, 1, 4) -- awesomephone has a 4 inch screen
ProductAttributes (2, 2, False) -- awesomephone has NO 4g
ProductAttributes (3, 3, 70) -- cooltv has a 70 inch screen
ProductAttributes (3, 4, True) -- cooltv has coax input
ProductAttributes (4, 3, 19) -- awesometv has a 19 inch screen
ProductAttributes (4, 4, False) -- awesometv has NO coax input
이 완전히 관계없는 이유는 여전히 값 유형을 평가해야한다는 것입니다 (bool, int 등)을 사용하여 코드에서 의미있는 방법으로 사용할 수 있습니다.
귀하의 모델은 SQL에서 유효하지만 ProductAttributes'는'ProductTypeAttributeId' 필드의 값에 각 행에 따라'에서'값 '컬럼의 도메인 이후 관계형 아닙니다. 1NF에서는 관계의 각 구성 요소가 단일 도메인을 가져야합니다. 예를 들어'ProductAttributes (1, 1, True)'는 유효한 행이 아니지만 외래 키 제약 조건을 사용하여 막을 수는 없습니다. EAV 모델은 관계형 모델에서 사용 된 것보다 더 높은 형태의 로직을 필요로합니다. – reaanb
나는 이해한다고 믿는다. 왜냐하면 어느 정도 정규화하려고해도 값이 bool인지 int인지를 결정하기 위해 항상 평가가 필요하기 때문에 결코 순수 관계형으로 간주 될 수 없기 때문입니다. – Forklift
네, 맞습니다. 어떤 경우에는 1NF가 아닌 데이터를 표현하는 SQL의 기능이 실제로 이점이 될 수 있지만 불일치가 발생하지 않도록 신중히 사용해야합니다. – reaanb
. 제품 이름, 설명, 비용, 가격 등 모든 유형에 공통적으로 사용되는 모든 열을 몇 가지 이름으로 지정할 수 있습니다. 따라서 자동 증가 ID가 아닙니다. 기본 키로 int 또는 long int 유형의 내부 ID를 갖는 것이 좋습니다.다른 필드 "코드"를 추가하거나 제품 관리 시스템에서 흔히 볼 수있는 사용자 입력 또는 사용자 친화적 인 사용자를 위해이 필드를 호출 할 수 있습니다. 검색 기준 또는 검색어 기준에 사용되는 경우 색인 생성을 확인하십시오.
HTH
가능하다면 잠시 시간을내어 내 대답이 관계형이 아닌 이유를 설명해 줄 수 있습니까? – Forklift