[sql] 엔티티 속성 값 데이터베이스 대 엄격한 관계형 모델 전자 상거래

EAV / CR 데이터베이스 모델이 잘못 되었다고 말하는 것이 안전합니다 . 그것은 말했다

질문 : 런타임시 변경 될 수있는 전자 상거래 제품을 설명하는 속성의 “클래스”를 처리하기 위해 어떤 데이터베이스 모델, 기술 또는 패턴을 사용해야합니까?

좋은 전자 상거래 데이터베이스에는 옵션 클래스를 저장합니다 (예 : TV 해상도는 각 TV의 해상도를 갖지만 다음 제품은 TV가 아니고 “TV 해상도”가 아닐 수 있음). 어떻게 저장하고 효율적으로 검색하며 사용자가 제품을 설명하는 가변 필드로 제품 유형을 설정할 수 있습니까? 검색 엔진이 고객이 일반적으로 콘솔 깊이에 따라 TV를 검색하는 것을 발견하면 필드에 콘솔 깊이를 추가 한 다음 런타임에 각 TV 제품 유형에 대해 단일 깊이를 추가 할 수 있습니다.

좋은 전자 상거래 앱에는 유용한 제품들이 있습니다. 여기에는 일련의 제품이 표시되고 “TV 해상도”를 헤더로 볼 수있는 “드릴 다운”사이드 메뉴가 있으며 가장 일반적인 5 가지 TV 해상도는 발견 세트. 하나를 클릭하면 해당 해상도의 TV 만 표시되므로 사이드 메뉴에서 다른 범주를 선택하여 드릴 다운 할 수 있습니다. 이러한 옵션은 런타임에 추가 된 동적 제품 속성입니다.

심도 깊은 논의:

간단히 말해 인터넷이나 모델 설명에 다음과 같은 설정을 “수정 적으로”수정할 수있는 링크가 있습니까? Noel Kennedy에게 카테고리 테이블을 제안 해 주셔서 감사하지만 그보다 더 큰 필요성이있을 수 있습니다. 의미를 강조하기 위해 아래에 다른 방법으로 설명합니다. 문제를 해결하기 위해 시점 수정이 필요하거나 EAV / CR에 대해 더 깊이 들어가야 할 수도 있습니다.

EAV / CR 모델에 대한 긍정적 인 반응을 좋아하십시오. 저의 동료 개발자들은 모두 Jeffrey Kemp가 아래에서 언급 한 내용을 말합니다. 문제는:

  • 엔티티 추가 및 제거 매주 속성
    (키워드는 미래의 속성을 지시 검색)
  • 새로운 엔티티가 매주 도착합니다
    (제품은 부품으로 조립됩니다)
  • 오래된 엔티티는 매주 사라짐
    (아카이브, 덜 인기있는, 계절별)

고객이 다음 두 가지 이유로 제품에 속성을 추가하려고합니다.

  • 유사 제품 간의 부서 / 키워드 검색 / 비교 차트
  • 결제 전 소비자 제품 구성

속성은 키워드 검색뿐만 아니라 의미를 가져야합니다. “휘핑 크림 프로스팅”이있는 모든 케이크를 비교하려면 케이크를 클릭하고 생일 테마를 클릭하고 휘핑 크림 프로스팅을 클릭 한 다음 크림 프로스팅이 모두 휘핑되어 있다는 사실을 알고 흥미로운 모든 케이크를 확인할 수 있습니다. 이것은 케이크에만 국한된 것이 아니라 단지 예일뿐입니다.



답변

내가 생각할 수있는 몇 가지 일반적인 장단점이 있습니다. 하나가 다른 것보다 더 나은 상황이 있습니다.

옵션 1, EAV 모델 :

  • 장점 : 간단한 응용 프로그램을 설계하고 개발하는 시간이 줄어 듭니다.
  • 프로 : 쉽게 추가 할 수있는 새로운 엔터티 (사용자가 추가 할 수도 있습니까?)
  • 프로 : “일반적인”인터페이스 구성 요소
  • 단점 : 간단한 데이터 형식을 확인하는 데 필요한 복잡한 코드
  • 단점 : 간단한 보고서를위한 훨씬 더 복잡한 SQL
  • 단점 : 복잡한 보고서가 거의 불가능해질 수 있습니다
  • 단점 : 대용량 데이터 세트의 성능 저하

옵션 2, 각 엔티티를 개별적으로 모델링 :

  • 단점 : 요구 사항 및 디자인을 수집하는 데 더 많은 시간이 필요
  • 단점 : 새로운 실체는 전문가가 모델링하고 설계해야합니다.
  • 단점 : 각 엔터티에 대한 사용자 지정 인터페이스 구성 요소
  • 장점 : 구현하기 쉬운 데이터 형식 제약 조건 및 유효성 검사
  • 장점 : SQL은 작성, 이해 및 디버깅이 용이합니다.
  • 장점 : 가장 복잡한 보고서조차도 비교적 간단합니다
  • Pro : 대용량 데이터 세트를위한 최고의 성능

옵션 3, 조합 (모델 엔터티는 “적절하게”있지만 일부 / 모든 엔터티에 대한 사용자 지정 특성에 대해서는 “확장”을 추가합니다)

  • Pro / Con : 옵션 1보다 요구 사항과 디자인을 수집하는 데 더 많은 시간이 필요하지만 옵션 2만큼 많지는 않습니다. *
  • 단점 : 새로운 실체는 전문가가 모델링하고 설계해야합니다.
  • Pro : 나중에 새로운 속성을 쉽게 추가 할 수 있습니다
  • 단점 : 간단한 데이터 형식의 유효성을 검사하는 데 필요한 복잡한 코드 (사용자 지정 특성의 경우)
  • 단점 : 사용자 정의 인터페이스 구성 요소는 여전히 필요하지만 사용자 정의 속성에 일반 인터페이스 구성 요소가 가능할 수 있습니다
  • 단점 : 사용자 지정 특성이 보고서에 포함 되 자마자 SQL이 복잡해집니다.
  • 단점 : 사용자 지정 특성으로 검색하거나보고 할 필요가없는 한 일반적으로 우수한 성능

* 옵션 3이 설계 단계에서 시간을 절약 할 수 있을지 확실하지 않습니다.

개인적으로 나는 옵션 2에 의지하고 가능한 한 EAV를 피할 것입니다. 그러나 일부 시나리오의 경우 사용자는 EAV와 함께 제공되는 유연성이 필요합니다. 그러나 이것은 큰 비용이 듭니다.


답변

EAV / CR 데이터베이스 모델이 잘못되었다고 말하는 것이 안전합니다.

아뇨. 단지 관계형 데이터베이스를 비효율적으로 사용한다는 것입니다. 순수 키 / 값 저장소는이 모델에서 효과적입니다.

이제 실제 질문에 : 다양한 속성을 저장하고 검색 가능한 상태로 유지하는 방법은 무엇입니까?

EAV를 사용하십시오. 귀하의 경우 단일 추가 테이블이됩니다. 대부분의 RDBM은 속성 이름과 값 모두에 색인을 지정하여 속성 이름 반복에 접두사 압축을 사용하여 실제로 빠르고 컴팩트하게 만듭니다.

EAV / CR을 사용하여 ‘실제’필드를 바꾸면 추악 해집니다. 모든 도구와 마찬가지로 도구를 과도하게 사용하면 ‘나쁜’이미지가됩니다.


답변

//이 시점에서 Magento / Adobe PSD 형식에 대해 말씀 드리겠습니다 .
// Magento / PSD 는 좋은 전자 상거래 플랫폼 / 형식 이 아닙니다 . Magento / PSD 도 나쁜 전자 상거래 플랫폼 / 형식 이 아닙니다 . 그것을 그렇게 부르는 것은
// Zencart 또는 OsCommerce와 같은 다른 나쁜 전자 상거래 플랫폼 / 포맷 에 모욕적입니다. 아니요, Magento / PSD 는 끔찍한 전자 상거래 플랫폼 / 형식 입니다. 데
// 몇 주 동안이 코드 작업을 마쳤습니다. Magento / PSD에 대한 증오 가 격렬한 화염 에 휩싸였습니다
// 백만 태양의 격렬한 열정으로 불타고 있습니다.

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

내부 모델은 누군가 멍청이 게임에 스키마를 넣고 그것을 밀봉하여 페인트 해커에 넣는 것처럼 기괴합니다.

실제 : 저는 미들웨어 이행 앱을 개발 중이며 주소 정보를 얻기위한 쿼리 중 하나입니다.

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id,
       sales_order_entity.entity_id,
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type,
       GROUP_CONCAT(
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!'
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

주문에 대한 정확한 주소 정보, 지연

요약 : 다음과 같은 경우 에만 마 젠토를 사용하십시오.

  1. 많은 돈을 받고 있습니다
  2. 당신은해야합니다
  3. 고통을 즐기십시오

답변

NoSQL 데이터베이스를 언급 한 사람이 아무도 없습니다.

프로덕션 컨텍스트에서 NoSQL을 연습 한 적이 없었습니다 (MongoDB를 테스트하고 감동했습니다). NoSQL의 요점은 다양한 속성을 가진 항목을 동일한 “문서”에 저장할 수 있습니다.


답변

ETL 유형의 응용 프로그램에서와 같이 성능이 주요 요구 사항이 아닌 경우 EAV에는 또 다른 이점이 있습니다. 차등 저장.

나는 초과 요구 사항이 도메인 객체의 히스토리를 첫 번째 “버전”에서 현재 상태로 볼 수있는 기능인 여러 애플리케이션을 구현했습니다. 해당 도메인 개체에 많은 수의 특성이있는 경우 각 변경 시마다 새 행을 해당 테이블에 삽입해야합니다 (히스토리가 유실되므로 업데이트가 아니라 삽입). 이 도메인 객체가 Person이라고 가정하고 Persons 수명주기 동안 다양한 속성으로 평균 100 회 이상의 변경 사항을 추적 할 수있는 500k Persons가 있다고 가정하겠습니다. 단 하나의 주요 도메인 개체를 가진 응용 프로그램이 드물다는 사실과 함께 데이터베이스 크기가 빠르게 제어 할 수 없게된다는 사실을 빨리 알게 될 것입니다.

쉬운 해결책은 중복 정보를 반복적으로 저장하지 않고 주요 도메인 개체에 대한 차등 변경 사항 만 저장하는 것입니다.

모든 비즈니스 모델은 새로운 비즈니스 요구를 반영하기 위해 시간이 지남에 따라 변경됩니다. 기간. EAV 사용은 박스에서 사용할 도구 중 하나 일뿐입니다. 그러나 자동으로 “나쁜”것으로 분류되어서는 안됩니다.


답변

나는 같은 문제로 고심하고 있습니다. 기존의 두 가지 전자 상거래 솔루션 인 Magento (EAV) 및 Joomla (정규 관계형 구조)에 대한 다음 논의를 확인하는 것이 흥미로울 수 있습니다.
https://forum.virtuemart.net/index.php?topic=58686.0

마젠 토의 EAV 성능은 실제 쇼퍼입니다.

그렇기 때문에 표준화 된 구조에 집중하고 있습니다. 유연성 부족을 극복하기 위해 나중에 편집 할 수있는 별도의 데이터 사전 (XML 또는 별도의 DB 테이블)을 추가 할 계획이며,이를 바탕으로 제품 범주를 표시하고 새로운 속성 세트를 비교하기위한 애플리케이션 코드는 다음과 같습니다. SQL 스크립트와 함께 생성됩니다.

이러한 경우 이러한 아키텍처는 유연하고 성능이 뛰어난 스위트 스폿으로 보입니다.

실제 환경에서 ALTER TABLE을 자주 사용하면 문제가 발생할 수 있습니다. Postgres를 사용하고 있으므로 MVCC와 트랜잭션 DDL이 고통을 덜어 줄 것입니다.


답변

나는 여전히 가장 낮은 의미의 EAV 원자 수준에서 모델링에 투표합니다. 컨텐츠 모델, 속성, 그레인 등의 반복 요구 사항을 결정하기 위해 특정 사용자 커뮤니티에 적합한 표준, 기술 및 응용 프로그램을 사용하십시오.