Trên thực tế, thiết kế bạn đã mô tả (bảng chung cộng với các bảng cụ thể cho loại phụ) được gọi là Kế thừa bảng lớp .
Kế thừa Bảng Bê tông sẽ có tất cả các thuộc tính chung được sao chép trong các bảng kiểu con và bạn sẽ không có bảng siêu kiểu như hiện tại.
Tôi cực lực phản đối EAV. Tôi coi nó là một phản vật chất SQL. Nó có vẻ là một giải pháp thanh lịch vì nó yêu cầu ít bàn hơn, nhưng bạn đang tự đặt ra cho mình rất nhiều vấn đề đau đầu sau này. Bạn đã xác định được một vài nhược điểm, nhưng vẫn còn nhiều nhược điểm khác. IMHO, EAV chỉ được sử dụng một cách thích hợp nếu bạn hoàn toàn không được tạo một bảng mới khi bạn giới thiệu một kiểu con mới hoặc nếu bạn có số lượng kiểu con không giới hạn (ví dụ:người dùng có thể xác định các thuộc tính mới một cách đặc biệt).
Bạn có nhiều kiểu phụ, nhưng vẫn là một số hữu hạn trong số đó, vì vậy nếu tôi đang thực hiện dự án này, tôi sẽ gắn bó với Kế thừa bảng lớp . Bạn có thể có ít hàng của mỗi kiểu con, nhưng ít nhất bạn có một số đảm bảo rằng tất cả các hàng trong mỗi kiểu con có cùng cột, bạn có thể sử dụng NOT NULL nếu cần, bạn có thể sử dụng các kiểu dữ liệu SQL, bạn có thể sử dụng các ràng buộc toàn vẹn tham chiếu, v.v. Từ góc độ quan hệ, đây là một thiết kế tốt hơn EAV.
Một tùy chọn khác mà bạn chưa đề cập đến được gọi là LOB được tuần tự hóa . Đó là, thêm một cột BLOB cho một tập hợp các thuộc tính tùy chỉnh bán cấu trúc. Lưu trữ XML, YAML, JSON hoặc DSL của riêng bạn trong cột đó. Bạn sẽ không thể phân tích cú pháp các thuộc tính riêng lẻ ra khỏi BLOB đó một cách dễ dàng bằng SQL, bạn sẽ phải tìm nạp toàn bộ BLOB trở lại ứng dụng của mình và trích xuất các thuộc tính riêng lẻ trong mã. Vì vậy, theo một số cách, nó kém tiện lợi hơn. Nhưng nếu điều đó thỏa mãn việc sử dụng dữ liệu của bạn, thì không có gì sai với điều đó.
