Không, đây là một thiết kế tồi cho một cơ sở dữ liệu quan hệ. Đây là ví dụ về Thực thể-Thuộc tính-Giá trị thiết kế. Nó linh hoạt, nhưng nó phá vỡ hầu hết các quy tắc về ý nghĩa của việc trở thành một cơ sở dữ liệu quan hệ.
Trước khi bạn bắt đầu thiết kế EAV như một giải pháp cho cơ sở dữ liệu linh hoạt, hãy đọc câu chuyện này: CaRMa bị lỗi .
Cụ thể hơn, một số vấn đề với EAV bao gồm:
- Bạn không biết thuộc tính nào tồn tại cho bất kỳ ID_NUM đã cho nào nếu không truy vấn chúng.
- Bạn không thể đặt bất kỳ thuộc tính nào là bắt buộc, tương đương với NOT NULL.
- Bạn không thể sử dụng các ràng buộc cơ sở dữ liệu.
- Bạn không thể sử dụng các kiểu dữ liệu SQL; giá trị
valuecột phải là một VARCHAR dài. - Đặc biệt trong MySQL, mỗi VARCHAR được lưu trữ trên trang dữ liệu của chính nó, vì vậy điều này rất lãng phí.
Các truy vấn cũng vô cùng phức tạp khi bạn sử dụng thiết kế EAV. Magento, một nền tảng thương mại điện tử mã nguồn mở, sử dụng rộng rãi EAV và nhiều người dùng cho biết nó rất chậm và khó truy vấn nếu bạn cần các báo cáo tùy chỉnh.
Để trở thành quan hệ, bạn nên lưu trữ từng thuộc tính khác nhau trong cột riêng của nó, với tên riêng và một kiểu dữ liệu thích hợp.
Tôi đã viết thêm về EAV trong bản trình bày của mình Hướng đối tượng thực tế Mô hình trong SQL và trong bài đăng trên blog của tôi EAV FAIL và trong cuốn sách của tôi, Phản văn bản SQL:Tránh cạm bẫy của lập trình cơ sở dữ liệu .
