Tôi đã xem qua phần tạo Id của hướng dẫn tham khảo Hibernate và "tính bền bỉ của java với Hibernate"
Có khá nhiều tùy chọn có sẵn với Hibernate và JPA kết hợp.
Tôi đang tìm kiếm tài liệu bổ sung về cách chọn chiến lược tạo id cụ thể.
Tôi cũng đang tìm kiếm các điểm tới hạn.
Ví dụ, chiến lược hilo dự kiến sẽ giảm bớt sự tranh chấp. Tôi cho rằng phải có sự đánh đổi liên quan đến sự lựa chọn này.
Tôi muốn được giáo dục về sự đánh đổi.
Có tài liệu nào không?
Câu trả lời:
Các Doc API rất rõ ràng về vấn đề này.
Tất cả các trình tạo đều triển khai giao diện org.hibernate.id.IdentifierGenerator. Đây là một giao diện rất đơn giản. Một số ứng dụng có thể chọn cung cấp các triển khai chuyên biệt của riêng họ, tuy nhiên, Hibernate cung cấp một loạt các triển khai tích hợp sẵn. Các tên tắt cho các trình tạo tích hợp như sau:
tăng
tạo các mã định danh kiểu long, short hoặc int là duy nhất khi không có quy trình nào khác đang chèn dữ liệu vào cùng một bảng. Không sử dụng trong một cụm.
danh tính
hỗ trợ các cột nhận dạng trong DB2, MySQL, MS SQL Server, Sybase và HypersonicSQL. Định danh trả về có kiểu long, short hoặc int.
sự nối tiếp
sử dụng một trình tự trong DB2, PostgreSQL, Oracle, SAP DB, McKoi hoặc một trình tạo trong Interbase. Số nhận dạng được trả về thuộc loại long, short hoặc int
hilo
sử dụng thuật toán hi / lo để tạo hiệu quả các số nhận dạng kiểu long, short hoặc int, cho trước một bảng và cột (theo mặc định là hibernate_unique_key và next_hi tương ứng) làm nguồn giá trị hi. Thuật toán hi / lo tạo ra các số nhận dạng chỉ duy nhất cho một cơ sở dữ liệu cụ thể.
seqhilo
sử dụng thuật toán hi / lo để tạo hiệu quả các số nhận dạng kiểu long, short hoặc int, với một chuỗi cơ sở dữ liệu được đặt tên.
uuid
sử dụng thuật toán UUID 128 bit để tạo số nhận dạng của chuỗi loại là duy nhất trong mạng (địa chỉ IP được sử dụng). UUID được mã hóa dưới dạng một chuỗi dài 32 chữ số thập lục phân.
hướng dẫn
sử dụng chuỗi GUID do cơ sở dữ liệu tạo trên MS SQL Server và MySQL.
tự nhiên
chọn danh tính, trình tự hoặc hilo tùy thuộc vào khả năng của cơ sở dữ liệu bên dưới.
giao
cho phép ứng dụng gán một mã định danh cho đối tượng trước khi lệnh save () được gọi. Đây là chiến lược mặc định nếu không có phần tử nào được chỉ định.
lựa chọn
truy xuất khóa chính, được gán bởi trình kích hoạt cơ sở dữ liệu, bằng cách chọn hàng bằng một số khóa duy nhất và truy xuất giá trị khóa chính.
ngoại quốc
sử dụng định danh của một đối tượng liên kết khác. Nó thường được sử dụng cùng với một liên kết khóa chính.
trình tự-nhận dạng
một chiến lược tạo trình tự chuyên biệt sử dụng trình tự cơ sở dữ liệu để tạo giá trị thực, nhưng kết hợp điều này với JDBC3 getGeneratedKeys để trả về giá trị định danh đã tạo như một phần của quá trình thực thi câu lệnh chèn. Chiến lược này chỉ được hỗ trợ trên các trình điều khiển Oracle 10g được nhắm mục tiêu cho JDK 1.4. Nhận xét về các câu lệnh chèn này bị vô hiệu hóa do lỗi trong trình điều khiển Oracle.
Nếu bạn đang xây dựng một ứng dụng đơn giản với không nhiều người dùng đồng thời, bạn có thể sử dụng các bước tăng dần, nhận dạng, hilo, v.v. Đây là những ứng dụng đơn giản để cấu hình và không cần nhiều mã hóa bên trong db.
Bạn nên chọn trình tự hoặc hướng dẫn tùy thuộc vào cơ sở dữ liệu của bạn. Những thứ này an toàn và tốt hơn vì quá trình idtạo sẽ diễn ra bên trong cơ sở dữ liệu.
Cập nhật: Gần đây, chúng tôi đã gặp sự cố với idndity trong đó kiểu nguyên thủy (int), điều này đã được khắc phục bằng cách sử dụng kiểu warapper (Integer) thay thế.
Về cơ bản, bạn có hai lựa chọn chính:
@GeneratedValuechú thích và Hibernate sẽ chỉ định số nhận dạng cho bạn.Đối với các số nhận dạng đã tạo, bạn có hai tùy chọn:
Đối với định danh số, bạn có ba tùy chọn :
IDENTITY chỉ là một lựa chọn tốt khi bạn không thể sử dụng SEQUENCE (ví dụ: MySQL) vì nó vô hiệu hóa cập nhật hàng loạt JDBC .
SEQUENCE là tùy chọn ưu tiên, đặc biệt khi được sử dụng với trình tối ưu hóa mã định danh như gộp hoặc gộp chung-lo .
TABLE phải được tránh bằng bất kỳ giá nào vì nó sử dụng một giao dịch riêng biệt để lấy mã định danh và khóa cấp hàng có quy mô kém.
Một thời gian trước, tôi đã viết một bài báo chi tiết về trình tạo khóa Hibernate: http://blog.eyallupu.com/2011/01/hibernatejpa-identity-generators.html
Chọn đúng máy phát điện là một nhiệm vụ phức tạp nhưng điều quan trọng là phải thử và làm đúng càng sớm càng tốt - việc di chuyển muộn có thể là một cơn ác mộng.
Một chút lạc đề nhưng một cơ hội tốt để nêu ra một điểm thường bị bỏ qua, đó là chia sẻ khóa giữa các ứng dụng (thông qua API). Cá nhân tôi luôn thích khóa thay thế và nếu tôi cần giao tiếp các đối tượng của mình với các hệ thống khác, tôi không để lộ chìa khóa của mình (mặc dù đó là khóa thay thế) - tôi sử dụng thêm một 'khóa ngoài'. Với tư cách là một nhà tư vấn, tôi đã hơn một lần chứng kiến sự tích hợp hệ thống 'tuyệt vời' bằng cách sử dụng các khóa đối tượng (phương pháp tiếp cận 'nó ở đó, hãy cứ sử dụng nó') chỉ để tìm thấy một hoặc hai năm sau rằng một bên có vấn đề với phạm vi khóa hoặc điều gì đó của loại yêu cầu di chuyển sâu trên hệ thống làm lộ các khóa bên trong của nó. Để lộ khóa có nghĩa là bạn không nên để lộ một khía cạnh cơ bản của mã trước các ràng buộc bên ngoài.
Tôi thấy bài giảng này rất có giá trị https://vimeo.com/190275665 , ở điểm 3, nó tóm tắt các bộ tạo này và cũng đưa ra một số phân tích hiệu suất và hướng dẫn khi bạn sử dụng từng bộ phát.