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

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

---

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

The internal models are wacky at best, like someone put the schema into a boggle game, sealed that and put it in a paint shacker...

Real world: I'm working on a midware fulfilment app and here are one the queries to get address information.

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'

Exacts address information for an order, lazily

--

Summary: Only use Magento if:

1. You are being given large sacks of money
2. You must
3. Enjoy pain

---

I'm surprised nobody mentioned NoSQL databases.

I've never practiced NoSQL in a production context (just tested MongoDB and was impressed) but the whole point of NoSQL is being able to save items with varying attributes in the same "document".

---

Where performance is not a major requirement, as in an ETL type of application, EAV has another distinct advantage: differential saves.

I've implemented a number of applications where an over-arching requirement was the ability to see the history of a domain object from its first "version" to it's current state. If that domain object has a large number of attributes, that means each change requires a new row be inserted into it's corresponding table (not an update because the history would be lost, but an insert). Let's say this domain object is a Person, and I have 500k Persons to track with an average of 100+ changes over the Persons life-cycle to various attributes. Couple that with the fact that rare is the application that has only 1 major domain object and you'll quickly surmize that the size of the database would quickly grow out of control.

An easy solution is to save only the differential changes to the major domain objects rather than repeatedly saving redundant information.

All models change over time to reflect new business needs. Period. Using EAV is but one of the tools in our box to use; but it should never be automatically classified as "bad".

---

I'm struggling with the same issue. It may be interesting for you to check out the following discussion on two existing ecommerce solutions: Magento (EAV) and Joomla (regular relational structure): https://forum.virtuemart.net/index.php?topic=58686.0

It seems, that Magento's EAV performance is a real showstopper.

That's why I'm leaning towards a normalized structure. To overcome the lack of flexibility I'm thinking about adding some separate data dictionary in the future (XML or separate DB tables) that could be edited, and based on that, application code for displaying and comparing product categories with new attributes set would be generated, together with SQL scripts.

Such architecture seems to be the sweetspot in this case - flexible and performant at the same time.

The problem could be frequent use of ALTER TABLE in live environment. I'm using Postgres, so its MVCC and transactional DDL will hopefully ease the pain.

---

I still vote for modeling at the lowest-meaningful atomic-level for EAV. Let standards, technologies and applications that gear toward certain user community to decide content models, repetition needs of attributes, grains, etc.

---

If it's just about the product catalog attributes and hence validation requirements for those attributes are rather limited, the only real downside to EAV is query performance and even that is only a problem when your query deals with multiple "things" (products) with attributes, the performance for the query "give me all attributes for the product with id 234" while not optimal is still plenty fast.

One solution is to use the SQL database / EAV model only for the admin / edit side of the product catalog and have some process that denormalizes the products into something that makes it searchable. Since you already have attributes and hence it's rather likely that you want faceting, this something could be Solr or ElasticSearch. This approach avoids basically all downsides to the EAV model and the added complexity is limited to serializing a complete product to JSON on update.

---

EAV has many drawbacks:

1. Performance degradation over time Once the amount of data in the application grows beyond a certain size, the retrieval and manipulation of that data is likely to become less and less efficient.
2. The SQL queries are very complex and difficult to write.
3. Data Integrity problems. You can't define foreign keys for all the fields needed.
4. You have to define and maintain your own metadata.

---

I have a slightly different problem: instead of many attributes with sparse values (which is possibly a good reason to use EAV), I want to store something more like a spreadsheet. The columns in the sheet can change, but within a sheet all cells will contain data (not sparse).

I made a small set of tests to benchmark two designs: one using EAV, and the other using a Postgres ARRAY to store cell data.

EAV

Array

Both schemas have indexes on appropriate columns, and the indexes are used by the planner.

It turned out the array-based schema was an order of magnitude faster for both inserts and queries. From quick tests, it seemed that both scaled linearly. The tests aren't very thorough, though. Suggestions and forks welcome - they're under an MIT licence.

참고URL : https://stackoverflow.com/questions/870808/entity-attribute-value-database-vs-strict-relational-model-ecommerce