Sự miêu tả
Mỗi chiến lược và kỹ thuật trên đều có những ưu điểm và nhược điểm riêng. Các đề xuất chung để chọn một chiến lược cụ thể sẽ như sau:
Chiến lược TABLE_PER_CLASS dựa trên UNION
Chiến lược này được chọn tốt nhất nếu không yêu cầu các truy vấn và liên kết đa hình. Nếu bạn hiếm khi làm (hoặc hoàn toàn không làm) "chọn người dùng từ Người dùng người dùng". Nếu bạn không có bất kỳ lớp Thực thể nào tham chiếu đến Người dùng, thì đây là tùy chọn tốt nhất (vì bạn vẫn có thể thêm các liên kết và truy vấn đa hình được tối ưu hóa).
Chiến lược SINGLE_TABLE
Chiến lược này nên được sử dụng:
a) Chỉ làm những công việc đơn giản. Trong các tình huống mà việc chuẩn hóa và ràng buộc NOT NULL là rất quan trọng, nên ưu tiên chiến lược số 3 (THAM GIA). Thật hợp lý khi suy nghĩ xem liệu trong trường hợp này có đáng để từ bỏ hoàn toàn quyền thừa kế và thay thế bằng ủy quyền hay không.
b) Nếu cần có các truy vấn và liên kết đa hình, cũng như định nghĩa động của một lớp cụ thể trong thời gian chạy. Đồng thời, các lớp con khai báo tương đối ít trường mới và sự khác biệt chính với lớp cha là ở hành vi.
Và trên hết, bạn có một cuộc trò chuyện nghiêm túc với DBA.
CHIẾN LƯỢC THAM GIA
Chiến lược này là hiệu quả nhất xét về tốc độ và CÁC RÀNG BUỘC. Nó phù hợp trong trường hợp cần có các truy vấn và liên kết đa hình, nhưng các lớp con khai báo tương đối nhiều trường mới.
Một lời cảnh báo ở đây: quyết định giữa THAM GIA và TABLE_PER_CLASS yêu cầu đánh giá các kế hoạch thực hiện truy vấn trên dữ liệu thực, vì chiều rộng và chiều sâu của hệ thống phân cấp thừa kế có thể khiến chi phí tham gia (và kết quả là hiệu suất) không thể chấp nhận được.
Một cách riêng biệt, cần lưu ý rằng các chú thích kế thừa không thể được áp dụng cho các giao diện.
RÕ RÀNG
Cũng có thể xảy ra trường hợp bạn có hệ thống phân cấp các lớp Thực thể với chiến lược lưu trữ được chia sẻ trong cơ sở dữ liệu. Nhưng vì bất kỳ lý do gì, bạn không muốn một số lớp phân cấp được trả về khi một truy vấn được thực hiện trên lớp cơ sở.
Có một chú thích cho điều này:
@Polymorphism(type = PolymorphismType.EXPLICIT)Nếu chúng ta thêm nó vào lớp Client :
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Entity
class User {
int id;
String name;
LocalDate birthday;
}@Entity
class Employee extends User {
String occupation;
int salary;
LocalDate join;
}@Entity
@Polymorphism(type = PolymorphismType.EXPLICIT)
class Client extends User {
String address;
}Sau đó, các truy vấn HQL sẽ bỏ qua các đối tượng của lớp này khi truy vấn lớp cơ sở:
List<User> accounts = session.createQuery("from User").getResultList();Truy vấn này sẽ trả về một danh sách các đối tượng Người dùng và Nhân viên , nhưng không phải là Khách hàng .
GO TO FULL VERSION