Cơ sở dữ liệu giá trị thuộc tính thực thể so với mô hình quan hệ điện tử nghiêm ngặt

Có thể nói rằng mô hình cơ sở dữ liệu EAV / CR là xấu. Mà nói,

Câu hỏi: Mô hình cơ sở dữ liệu, kỹ thuật hoặc mẫu nào nên được sử dụng để đối phó với "các lớp" thuộc tính mô tả các sản phẩm thương mại điện tử có thể thay đổi trong thời gian chạy?

Trong cơ sở dữ liệu thương mại điện tử tốt, bạn sẽ lưu trữ các lớp tùy chọn (như độ phân giải TV sau đó có độ phân giải cho từng TV, nhưng sản phẩm tiếp theo có thể không phải là TV và không có "độ phân giải TV"). Làm thế nào để bạn lưu trữ chúng, tìm kiếm hiệu quả và cho phép người dùng của bạn thiết lập các loại sản phẩm với các trường biến mô tả sản phẩm của họ? Nếu công cụ tìm kiếm thấy rằng khách hàng thường tìm kiếm TV dựa trên độ sâu của bảng điều khiển, bạn có thể thêm độ sâu bảng điều khiển vào các trường của mình, sau đó thêm một độ sâu duy nhất cho từng loại sản phẩm TV trong thời gian chạy.

Có một tính năng phổ biến trong số các ứng dụng thương mại điện tử tốt, nơi chúng hiển thị một bộ sản phẩm, sau đó có các menu bên "đi sâu vào" nơi bạn có thể xem "Độ phân giải TV" làm tiêu đề và năm Độ phân giải TV phổ biến nhất cho tìm thấy bộ. Bạn nhấp vào một và nó chỉ hiển thị TV có độ phân giải đó, cho phép bạn xem chi tiết hơn bằng cách chọn các danh mục khác trên menu bên. Các tùy chọn này sẽ là các thuộc tính sản phẩm động được thêm vào lúc chạy.

Thảo luận thêm:

Câu chuyện dài quá, có bất kỳ liên kết nào trên Internet hoặc mô tả mô hình có thể "sửa chữa" về mặt học thuật không? Tôi cảm ơn Noel Kennedy đã gợi ý một bảng danh mục, nhưng nhu cầu có thể lớn hơn thế. Tôi mô tả nó theo một cách khác dưới đây, cố gắng làm nổi bật ý nghĩa. Tôi có thể cần điều chỉnh quan điểm để giải quyết vấn đề hoặc tôi có thể cần đi sâu hơn vào EAV / CR.

Thích phản ứng tích cực với mô hình EAV / CR. Tất cả các nhà phát triển đồng nghiệp của tôi đều nói những gì Jeffrey Kemp đã chạm vào bên dưới: "các thực thể mới phải được mô hình hóa và thiết kế bởi một chuyên gia" (đưa ra khỏi bối cảnh, đọc phản hồi của ông bên dưới). Vấn đề là:

• các thực thể thêm và xóa các thuộc tính hàng tuần
  (từ khóa tìm kiếm chỉ ra các thuộc tính trong tương lai)
• thực thể mới đến hàng tuần
  (sản phẩm được lắp ráp từ các bộ phận)
• các thực thể cũ biến mất hàng tuần
  (lưu trữ, ít phổ biến hơn, theo mùa)

Khách hàng muốn thêm thuộc tính cho sản phẩm vì hai lý do:

• biểu đồ tìm kiếm / so sánh giữa các bộ phận / từ khóa
• cấu hình sản phẩm tiêu dùng trước khi thanh toán

Các thuộc tính phải có ý nghĩa, không chỉ là một tìm kiếm từ khóa. Nếu họ muốn so sánh tất cả các loại bánh có "kem phủ kem", họ có thể nhấp vào bánh, nhấp vào chủ đề sinh nhật, nhấp vào kem phủ kem, sau đó kiểm tra tất cả các loại bánh thú vị khi biết tất cả chúng đều có kem phủ kem. Đây không phải là cụ thể cho bánh, chỉ là một ví dụ.

Có một vài ưu và nhược điểm chung mà tôi có thể nghĩ ra, có những tình huống mà cái này tốt hơn cái kia:

Tùy chọn 1, Mô hình EAV:

• Pro: ít thời gian hơn để thiết kế và phát triển một ứng dụng đơn giản
• Pro: thực thể mới dễ thêm (thậm chí có thể được thêm bởi người dùng?)
• Pro: thành phần giao diện "chung"
• Con: mã phức tạp cần thiết để xác thực các loại dữ liệu đơn giản
• Con: SQL phức tạp hơn nhiều cho các báo cáo đơn giản
• Con: báo cáo phức tạp có thể trở nên gần như không thể
• Con: hiệu suất kém cho các tập dữ liệu lớn

Tùy chọn 2, Mô hình hóa từng thực thể riêng biệt:

• Con: cần thêm thời gian để thu thập yêu cầu và thiết kế
• Con: các thực thể mới phải được mô hình hóa và thiết kế bởi một chuyên gia
• Con: thành phần giao diện tùy chỉnh cho từng thực thể
• Pro: ràng buộc kiểu dữ liệu và xác nhận đơn giản để thực hiện
• Pro: SQL dễ viết, dễ hiểu và gỡ lỗi
• Pro: ngay cả những báo cáo phức tạp nhất cũng tương đối đơn giản
• Pro: hiệu suất tốt nhất cho các tập dữ liệu lớn

Tùy chọn 3, Kết hợp (mô hình thực thể "đúng", nhưng thêm "tiện ích mở rộng" cho các thuộc tính tùy chỉnh cho một số / tất cả thực thể)

• Pro / Con: cần nhiều thời gian hơn để thu thập các yêu cầu và thiết kế so với tùy chọn 1 nhưng có lẽ không nhiều như tùy chọn 2 *
• Con: các thực thể mới phải được mô hình hóa và thiết kế bởi một chuyên gia
• Pro: các thuộc tính mới có thể dễ dàng được thêm vào sau này
• Con: mã phức tạp cần thiết để xác thực các loại dữ liệu đơn giản (đối với các thuộc tính tùy chỉnh)
• Con: các thành phần giao diện tùy chỉnh vẫn được yêu cầu, nhưng các thành phần giao diện chung có thể có thể cho các thuộc tính tùy chỉnh
• Con: SQL trở nên phức tạp ngay khi có bất kỳ thuộc tính tùy chỉnh nào được đưa vào báo cáo
• Con: hiệu suất tốt nói chung, trừ khi bạn bắt đầu cần tìm kiếm hoặc báo cáo theo các thuộc tính tùy chỉnh

* Tôi không chắc liệu Tùy chọn 3 có nhất thiết phải tiết kiệm bất kỳ thời gian nào trong giai đoạn thiết kế hay không.

Cá nhân tôi sẽ nghiêng về lựa chọn 2, và tránh EAV bất cứ khi nào có thể. Tuy nhiên, đối với một số tình huống, người dùng cần sự linh hoạt đi kèm với EAV; nhưng điều này đi kèm với một chi phí lớn.

Có thể nói rằng mô hình cơ sở dữ liệu EAV / CR là xấu.

Không, không phải vậy. Chỉ là họ sử dụng không hiệu quả các cơ sở dữ liệu quan hệ. Một kho lưu trữ khóa / giá trị thuần túy hoạt động tuyệt vời với mô hình này.

Bây giờ, với câu hỏi thực sự của bạn: Làm thế nào để lưu trữ các thuộc tính khác nhau và giữ cho chúng có thể tìm kiếm được?

Chỉ cần sử dụng EAV. Trong trường hợp của bạn, nó sẽ là một bảng phụ. lập chỉ mục cho cả tên và giá trị thuộc tính, hầu hết các RDBM sẽ sử dụng nén tiền tố để lặp lại tên thuộc tính, làm cho nó thực sự nhanh và gọn.

EAV / CR trở nên xấu khi bạn sử dụng nó để thay thế các trường 'thực'. Như với mọi công cụ, lạm dụng nó là 'xấu' và mang lại cho nó một hình ảnh xấu.

// Tại thời điểm này, tôi muốn dành một chút thời gian để nói chuyện với bạn về định dạng Magento / Adobe PSD .
// Magento / PSD không phải là một nền tảng / định dạng thương mại điện tử tốt . Magento / PSD thậm chí không phải là một nền tảng / định dạng thương mại điện tử tồi . Gọi nó như vậy sẽ là một
// xúc phạm đến các nền tảng / định dạng thương mại điện tử xấu khác , chẳng hạn như Zencart hoặc OsC Commerce. Không, Magento / PSD là một nền tảng / định dạng thương mại điện tử khổng lồ . Đang có
// đã làm việc với mã này trong vài tuần nay, sự ghét bỏ của tôi đối với Magento / PSD đã phát triển thành một đám cháy dữ dội
// bùng cháy với niềm đam mê mãnh liệt của một triệu mặt trời.

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

Các mô hình bên trong là tốt nhất, giống như ai đó đưa lược đồ vào một trò chơi boggle, niêm phong nó và đặt nó trong một shacker sơn ...

Thế giới thực: Tôi đang làm việc trên một ứng dụng hoàn thành phần mềm trung gian và đây là một trong những truy vấn để lấy thông tin địa chỉ.

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'

Chính xác thông tin địa chỉ cho một đơn đặt hàng, uể oải

-

Tóm tắt: Chỉ sử dụng Magento nếu:

1. Bạn đang được cho những bao tiền lớn
2. Bạn phải
3. Tận hưởng nỗi đau

Tôi ngạc nhiên không ai đề cập đến cơ sở dữ liệu NoQuery.

Tôi chưa bao giờ thực hành NoQuery trong bối cảnh sản xuất (vừa thử nghiệm MongoDB và đã rất ấn tượng) nhưng toàn bộ quan điểm của NoQuery là có thể lưu các mục với các thuộc tính khác nhau trong cùng một "tài liệu".

Trong đó hiệu suất không phải là một yêu cầu chính, như trong một loại ứng dụng ETL, EAV có một lợi thế khác biệt: tiết kiệm vi sai.

Tôi đã triển khai một số ứng dụng trong đó yêu cầu quá cao là khả năng xem lịch sử của một đối tượng miền từ "phiên bản" đầu tiên của nó sang trạng thái hiện tại. Nếu đối tượng miền đó có số lượng thuộc tính lớn, điều đó có nghĩa là mỗi thay đổi yêu cầu một hàng mới được chèn vào bảng tương ứng của nó (không phải là một bản cập nhật vì lịch sử sẽ bị mất, mà là một phần chèn). Giả sử đối tượng miền này là một Người và tôi có 500 nghìn Người để theo dõi với trung bình hơn 100 thay đổi trong vòng đời của Người đối với các thuộc tính khác nhau. Kết hợp với thực tế là hiếm có ứng dụng chỉ có 1 đối tượng tên miền chính và bạn sẽ nhanh chóng phỏng đoán rằng kích thước của cơ sở dữ liệu sẽ nhanh chóng vượt khỏi tầm kiểm soát.

Một giải pháp dễ dàng là chỉ lưu các thay đổi khác biệt cho các đối tượng miền chính thay vì liên tục lưu thông tin dư thừa.

Tất cả các mô hình thay đổi theo thời gian để phản ánh nhu cầu kinh doanh mới. Giai đoạn = Stage. Sử dụng EAV là một trong những công cụ trong hộp của chúng tôi để sử dụng; nhưng nó không bao giờ nên được tự động phân loại là "xấu".

Tôi đang vật lộn với cùng một vấn đề. Có thể bạn sẽ thấy thú vị khi xem cuộc thảo luận sau đây về hai giải pháp thương mại điện tử hiện có: Magento (EAV) và Joomla (cấu trúc quan hệ thông thường): https://forum.virtuemart.net/index.php?topic=58686.0

Có vẻ như, hiệu suất EAV của Magento là một showstopper thực sự.

Đó là lý do tại sao tôi nghiêng về một cấu trúc bình thường. Để khắc phục sự thiếu linh hoạt Tôi nghĩ đến việc thêm một số từ điển dữ liệu riêng trong tương lai (các bảng DB hoặc DB riêng biệt) có thể được chỉnh sửa và dựa vào đó, mã ứng dụng để hiển thị và so sánh các danh mục sản phẩm với các thuộc tính mới sẽ được đặt được tạo, cùng với các tập lệnh SQL.

Kiến trúc như vậy dường như là đồ ngọt trong trường hợp này - linh hoạt và biểu diễn cùng một lúc.

Vấn đề có thể là việc sử dụng thường xuyên ALTER TABLE trong môi trường sống. Tôi đang sử dụng Postgres, vì vậy MVCC và DDL giao dịch của nó hy vọng sẽ giảm bớt nỗi đau.

Tôi vẫn bỏ phiếu cho mô hình hóa ở cấp độ nguyên tử có ý nghĩa thấp nhất cho EAV. Hãy để các tiêu chuẩn, công nghệ và ứng dụng hướng đến cộng đồng người dùng nhất định để quyết định mô hình nội dung, nhu cầu lặp lại của các thuộc tính, hạt, v.v.

Nếu đó chỉ là về các thuộc tính danh mục sản phẩm và do đó các yêu cầu xác thực cho các thuộc tính đó khá hạn chế, thì nhược điểm thực sự duy nhất đối với EAV là hiệu năng truy vấn và thậm chí đó chỉ là vấn đề khi truy vấn của bạn xử lý nhiều "điều" (sản phẩm) với các thuộc tính, hiệu suất cho truy vấn "cung cấp cho tôi tất cả các thuộc tính cho sản phẩm có id 234" trong khi không tối ưu vẫn rất nhanh.

Một giải pháp là chỉ sử dụng mô hình cơ sở dữ liệu / EAV của SQL cho phía quản trị / chỉnh sửa của danh mục sản phẩm và có một số quy trình không chuẩn hóa các sản phẩm thành thứ gì đó có thể tìm kiếm được. Vì bạn đã có các thuộc tính và do đó, có vẻ như bạn muốn phân tích, nên thứ này có thể là Solr hoặc ElasticSearch. Cách tiếp cận này về cơ bản tránh được tất cả các nhược điểm của mô hình EAV và độ phức tạp thêm vào được giới hạn trong việc tuần tự hóa một sản phẩm hoàn chỉnh thành JSON khi cập nhật.

EAV có nhiều nhược điểm:

1. Suy giảm hiệu suất theo thời gian Một khi lượng dữ liệu trong ứng dụng tăng vượt quá một kích thước nhất định, việc truy xuất và thao tác dữ liệu đó có thể sẽ trở nên ít hơn và kém hiệu quả hơn.
2. Các truy vấn SQL rất phức tạp và khó viết.
3. Vấn đề toàn vẹn dữ liệu. Bạn không thể xác định khóa ngoại cho tất cả các trường cần thiết.
4. Bạn phải xác định và duy trì siêu dữ liệu của riêng bạn.

Tôi có một vấn đề hơi khác: thay vì nhiều thuộc tính có giá trị thưa thớt (có thể là lý do chính đáng để sử dụng EAV), tôi muốn lưu trữ một cái gì đó giống như bảng tính. Các cột trong trang tính có thể thay đổi, nhưng trong một trang tính, tất cả các ô sẽ chứa dữ liệu (không thưa thớt).

Tôi đã thực hiện một bộ thử nghiệm nhỏ để điểm chuẩn hai thiết kế: một thiết kế sử dụng EAV và thiết kế còn lại sử dụng ARRAY Postgres để lưu trữ dữ liệu di động.

EAV

Mảng

Cả hai lược đồ đều có các chỉ mục trên các cột thích hợp và các chỉ mục được sử dụng bởi trình hoạch định.

Hóa ra lược đồ dựa trên mảng là một thứ tự cường độ nhanh hơn cho cả chèn và truy vấn. Từ các thử nghiệm nhanh, dường như cả hai đều có tỷ lệ tuyến tính. Các xét nghiệm không phải là rất kỹ lưỡng, mặc dù. Đề xuất và dĩa được chào đón - chúng thuộc giấy phép MIT.