Hibernate/JPA DB Schema Generation Thực tiễn tốt nhất

Question

Tôi chỉ muốn nghe ý kiến ​​của các chuyên gia Hibernate về các phương pháp thực hành tốt nhất cho các lược đồ DB cho các dự án dựa trên Hibernate/JPA. Đặc biệt:

1. Chiến lược nào sẽ sử dụng khi dự án vừa mới bắt đầu? Có nên để Hibernate tự động tạo lược đồ trong giai đoạn này hay tốt hơn là tạo các bảng cơ sở dữ liệu theo cách thủ công từ các giai đoạn sớm nhất của dự án?

2. Giả sử rằng trong suốt dự án, lược đồ đã được tạo bằng Hibernate, tốt hơn là vô hiệu hóa tạo lược đồ tự động và tạo thủ công giản đồ cơ sở dữ liệu ngay trước khi hệ thống được phát hành vào sản xuất?

3. Và sau khi hệ thống được đưa vào sản xuất, thực tiễn tốt nhất để duy trì các lớp thực thể và lược đồ DB (ví dụ: thêm/đổi tên/cập nhật cột, đổi tên bảng, v.v.) là gì?

Answer 1

1. Nó luôn luôn khuyến khích để tạo ra các sơ đồ bằng tay, tốt nhất là bằng một công cụ hỗ trợ các phiên bản giản đồ cơ sở dữ liệu, chẳng hạn như lớn Liquibase. Việc tạo lược đồ từ các thực thể là rất lớn về mặt lý thuyết, nhưng rất mong manh trong thực tế và gây ra rất nhiều vấn đề trong thời gian dài (tin tưởng tôi về điều này).

2. Trong sản xuất, tốt nhất nên tạo thủ công và xem xét lược đồ.

3. Bạn cập nhật thực thể và tạo tập lệnh cập nhật phù hợp (bản sửa đổi) để cập nhật giản đồ cơ sở dữ liệu của bạn để phản ánh thay đổi đối tượng. Bạn có thể tạo một giải pháp tùy chỉnh (tôi đã viết một vài) hoặc sử dụng một cái gì đó phổ biến hơn như liquibase (nó thậm chí còn hỗ trợ các thay đổi lược đồ thay đổi). Nếu bạn đang sử dụng công cụ xây dựng như maven hoặc ant - bạn nên cắm bản cập nhật lược đồ db vào quá trình xây dựng để các bản dựng mới luôn đồng bộ với lược đồ.

Answer 2

Mặc dù có thể tranh cãi, tôi muốn nói câu trả lời cho cả 3 câu hỏi là: hãy để hibernate tự động tạo các bảng trong lược đồ.

Tôi chưa gặp phải bất kỳ sự cố nào với điều này. Bạn có thể cần phải dọn dẹp một số trường theo cách thủ công, nhưng điều này không đau đầu so với việc theo dõi riêng các kịch bản DDL - tức là quản lý các bản sửa đổi và đồng bộ hóa chúng với các thay đổi thực thể (và ngược lại)

Để triển khai về sản xuất - một mẹo rõ ràng - trước tiên hãy đảm bảo mọi thứ được tạo OK trên môi trường thử nghiệm và sau đó triển khai trên sản xuất.

Answer 3

thủ, bởi vì:

1. Cùng cơ sở dữ liệu có thể được sử dụng bởi các ứng dụng khác nhau và không phải tất cả họ sẽ sử dụng chế độ ngủ đông hoặc thậm chí java. Lược đồ cơ sở dữ liệu nên không được quyết định bởi ORM, nó phải được thiết kế xung quanh dữ liệu và yêu cầu kinh doanh .
2. Các kiểu dữ liệu được chọn bởi ngủ đông có thể không phù hợp nhất với ứng dụng.
3. Như đã đề cập trong một nhận xét trước đó, các thay đổi đối với các thực thể sẽ yêu cầu can thiệp thủ công nếu mất dữ liệu không được chấp nhận.
4. Những thứ như thuộc tính bổ sung (thuật ngữ chung không java thuộc tính) trên bàn làm việc tuyệt vời trong RDBMS nhưng là hơi phức tạp và không hiệu quả để sử dụng trong ORM. Thực hiện ánh xạ từ ORM -> RDBMS có thể tạo các bảng không phải là hiệu quả. Về lý thuyết, có thể xây dựng chính xác cùng một bảng tham gia bằng cách sử dụng mã được tạo hibernate, nhưng nó sẽ yêu cầu một số sự chăm sóc đặc biệt trong khi viết các thực thể.

Tôi sẽ sử dụng thế hệ tự động cho các ứng dụng độc lập hoặc cơ sở dữ liệu được truy cập qua cùng một lớp ORM và cũng có thể ứng dụng cần được chuyển sang cơ sở dữ liệu khác. Nó sẽ tiết kiệm rất nhiều thời gian bằng cách không yêu cầu một người viết và duy trì các kịch bản DDL cụ thể của nhà cung cấp DB.

Answer 4

Giống như Bozhidar đã nói, đừng để Hibernate tạo & cập nhật giản đồ cơ sở dữ liệu. Hãy để ứng dụng của bạn tạo và cập nhật giản đồ cơ sở dữ liệu. Đối với java công cụ tốt nhất để làm điều này là Flyway. Bạn cần tạo một hoặc nhiều tệp SQL với các câu lệnh DDL mô tả lược đồ cơ sở dữ liệu của bạn. Các tệp SQL này sau đó được thực thi bởi Flyway. Để biết thêm thông tin, hãy xem trang web Flyway.

Answer 5

Tôi tin rằng rất nhiều những gì đang được thảo luận hoặc tranh cãi ở đây cũng nên liên quan đến nếu bạn có nhiều confortable với cách đầu tiên mã hoặc đầu tiên cơ sở dữ liệu.

Cá nhân, tôi dự định đi sau và, tham chiếu đến Nguyên tắc chịu trách nhiệm duy nhất (SRP), tôi thích có chuyên gia DB xử lý DB và chuyên gia ứng dụng xử lý ứng dụng hơn là ứng dụng xử lý DB . Ngoài ra, tôi có ý kiến ​​rằng việc sử dụng quá nhiều phím tắt sẽ hoạt động tốt ngay từ đầu nhưng tạo ra các vấn đề không thể quản lý khi mọi thứ phát triển/phát triển.