Tại sao? Làm tất cả các thực thể của bạn yêu cầu được mở rộng theo cách này? Có lẽ là không - trong hầu hết các ứng dụng chỉ có một hoặc hai thực thể có thể được hưởng lợi từ mức độ linh hoạt này. Các thực thể khác thực sự được hưởng lợi từ sự ổn định và rõ ràng của not luôn thay đổi.
EAV là một ví dụ về Hiệu ứng nền tảng bên trong :
Nói cách khác, bây giờ bạn có trách nhiệm viết mã ứng dụng để thực hiện tất cả những thứ mà một RDBMS thích hợp đã cung cấp, chẳng hạn như các ràng buộc và kiểu dữ liệu. Ngay cả những thứ đơn giản như bắt buộc một cột như NOT NULL không hoạt động trong EAV.
Đúng là đôi khi một dự án cần rất nhiều bảng. Nhưng bạn đang tự đánh lừa mình nếu bạn nghĩ rằng bạn đã đơn giản hóa dự án bằng cách chỉ lập hai bảng. Bạn vẫn sẽ có nhiều Đối tượng riêng biệt như khi bạn có các bảng, nhưng bây giờ tùy thuộc vào bạn để giữ chúng không biến thành một đống rác.
Trước khi bạn đầu tư quá nhiều thời gian vào EAV, hãy đọc câu chuyện này về một công ty gần như ngừng hoạt động vì ai đó đã cố gắng biến kho dữ liệu của họ trở nên linh hoạt một cách tùy tiện:Bad CaRMa .
Tôi cũng đã viết thêm về EAV trong một bài đăng trên blog, EAV FAIL và trong một chương của 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 .
