Entity – Attribute – Value table (EAV: Phần tử – Thuộc tính- Bảng giá trị)
Lý tưởng thì một bảng sẽ thể hiện một bộ các phần tử, mỗi phần tử của bảng có một bộ các thuộc tính được thể hiện qua các cột. Đôi khi, các nhà thiết kế có thể bị cuốn vào một thế giới “mô hình” (paradigms) lập trình thay thế và cố gắng thiết lập chúng. Một mô hình như thế được gọi là mô hình Phần tử – Thuộc tính – Giá trị (hoặc trong một số ngữ cảnh gọi là object-attribute-model), đó cũng là tên thường gọi cho một bảng có 3 cột, một cột đại diện cho kiểu dữ liệu của phần tử, một cột dành cho thông số hoặc thuộc tính hay tính chất của phần tử đó và cột thứ ba là giá trị thực tế của tính chất đó.
Hãy xem qua ví dụ bên dưới về một bảng ghi lại những dữ liệu của nhân viên:
Hình 7
Lúc này phương pháp EAV đảo lộn các dữ liệu nhằm thể hiện các thuộc tính dưới dạng các giá trị ở một cột và các giá trị tương ứng với các thuộc tính đó nằm ở cột khác.
Hình 8
Tới đây thôi, không cần phải có thêm nhiều bảng, tất cả các dữ liệu đều có thể được để chung vào một bảng duy nhất. Phát minh này được biết đến nhờ vào vai trò của những nhà thiết kế CSDL đơn giản, những người này quyết định rằng khi các yếu tố dữ liệu là vô danh, được nhận biết một phần hoặc khó nhận biết thì tốt nhất là dùng EAV. Vấn đề là những người mới rất chuộng việc áp dụng phương pháp này trong CSDL SQL và hậu quả thường là một mớ hỗn loạn. Thực tế, nhiều người cho rằng thật may mắn khi họ không biết bản chất của dữ liệu.
Thế thì những lợi ích nào được đưa ra đối với EAV? Vâng, chẳng có lợi ích nào cả. Vì các bảng EAV chứa bất cứ kiểu dữ liệu nào nên chúng ta phải cố định dữ liệu ở một vùng giới hạn trong bảng với những cột thích hợp nhằm sử dụng chúng hiệu quả. Trong nhiều trường hợp, có những phần mềm client-side hoặc middleware sẽ ngầm thực hiện việc này, do đó sẽ khiến cho người dùng nhầm tưởng rằng mình đang làm việc với dữ liệu được thiết kế tốt.
Mô hình EAV có một hệ thống các vấn đề.
- Đầu tiên, lượng dữ liệu lớn không thể kiểm soát chính nó được.
- Thứ hai, không có cách khả thi nào để xác định những ràng buộc cần thiết – bất cứ ràng buộc kiểm tra tiềm năng nào cũng sẽ phải bao gồm việc tạo ra mã cứng trên diện rộng cho các tên thuộc tính thích hợp. Chính vì một cột đơn lẻ chứa tất cả các giá trị có thể nên kiểu dữ liệu thường là VARCHAR(n).
- Thứ ba, đừng bao giờ nghĩ về chuyện có những khóa ngoại hữu dụng.
- Thứ tư, truy vấn (query) luôn có những phức tạp và rắc rối. Một số người cho rằng sẽ có lợi khi có thể chèn nhiều dữ liệu vào cùng một bảng khi cần thiết – họ gọi đó là tính “có khả năng thay đổi”. Trong thực tế, vì EAV trộn lẫn dữ liệu và lý lịch dữ liệu nên càng khó hơn để điều khiển dữ liệu ngay cả trong những yêu cầu đơn giản. Hãy xem xét một truy vấn đơn giản để gọi ra những nhân viên sinh sau năm 1950. Với mô hình truyền thống, ta có:
Trong một mô hình EAV, đây là một cách để viết một truy vấn có thể so sánh được:
List 1
Với những ai có kinh nghiệm với transact-SQL thì cứ thêm vài cột mới vào kèm theo các kiểu dữ liệu khác và thử vài truy vấn để kiểm tra kết quả.
Giải pháp cho cơn ác mộng EAV thì lại khá đơn giản: Phân tích và nghiên cứu xem nhu cầu của người dùng là gì và xác định yêu cầu dữ liệu một cách cởi mở. Một CSDL quan hệ sẽ duy trì tính toàn vẹn và nhất quán của dữ liệu Gần như là bất khả thi để tạo ra một trường hợp (case) thiết kế một CSDL như thế mà không có yêu cầu đã được xác định cẩn thận
