Khi sử dụng ORM, một số điều cần chú ý trong thiết kế cơ sở dữ liệu của bạn

19

Một số vấn đề thiết kế cơ sở dữ liệu cần chú ý khi bạn biết cơ sở dữ liệu sẽ được truy cập bằng cách sử dụng Wikipedia Mapper quan hệ đối tượng (ORM) ? Đồng thời xem Entity Framework NHibernate hoặc LLBLGenPro.

Ví dụ, tôi sẽ lưu ý giới hạn tham số 2100 trong cuộc gọi RPC của SqlServer. Đây là một vấn đề khi sử dụng LLBLgen và nối các bảng khi các khóa chính được sử dụng, xem bài viết MSDN cho các khóa ghép .

performance orm

— BozoJoe
nguồn

4

Không vi phạm, nhưng "tham gia các bảng có nhiều hơn 1 khóa chính" .. điều này xác định lại một trong các quy tắc cơ bản của một bảng, một PK cho mỗi bảng. Chính xác ý bạn là gì?

— Mary

Làm thế nào để điều này đạt giới hạn tham số 2100? Bạn có bảng với nhiều cột không? Ngoài ra, tôi cho rằng bạn có nghĩa là "Lập bản đồ quan hệ đối tượng" chứ không phải "Mô hình hóa vai trò đối tượng"

— John Saunders

Giới hạn tham số 2100 đôi khi là một vấn đề nếu bạn chuyển một danh sách lớn các giá trị cho SQL 'IN' (mảng LINQ.Contains (thành viên)). Tuy nhiên, điều đó thực sự không có gì để thiết kế cơ sở dữ liệu; đó là nhiều hơn một vấn đề mẫu truy vấn. Cách giải quyết đơn giản nhất cho các ORM 'chịu đựng' từ đó là chèn danh sách vào bảng tạm thời [vĩnh viễn] và tham gia vào đó và / hoặc sử dụng truy vấn con chọn các mục sẽ được truy vấn từ bất cứ nơi nào chúng xuất phát. (chuyển hàng ngàn mục vào SQL 'IN' nói chung là không tốt, cho dù bạn có đang sử dụng trình ánh xạ OR hay không).

— KristoferA

@ John, có Bản đồ quan hệ đối tượng

— BozoJoe

4

@BozoJoe: một bảng có thể - theo định nghĩa - chỉ có một khóa chính. Không có DBMS nào cho phép bạn xác định nhiều hơn một khóa chính cho một bảng.

— a_horse_with_no_name

17

Trải qua các kỹ thuật chuẩn hóa tiêu chuẩn, chủ yếu là dạng thứ 3. Một số ORM có thể chọn các mối quan hệ được xác định ở cấp cơ sở dữ liệu để bạn không phải thủ công.

Tôi thực sự sẽ đi theo con đường khác và hỏi tôi nên biết gì về ORM. Hãy chắc chắn rằng bạn biết: - Làm cách nào để tôi lập hồ sơ các truy vấn? - Làm cách nào tôi có thể ghi đè ORM và viết truy vấn của riêng mình? - Tôi có thể sử dụng procs được lưu trữ thay thế?

Cơ sở dữ liệu phải là bất khả tri ORM vì, nhiều khả năng, nó sẽ tồn tại lâu hơn ứng dụng.

— Eric Humphrey - rất nhiều
nguồn

+1: "Cơ sở dữ liệu phải là thuyết bất khả tri". Bám sát các tiêu chuẩn cho thiết kế cơ sở dữ liệu và các ORM tốt cũng sẽ rất vui.

— MicSim

12

Không bao giờ để ORM tạo hoặc cập nhật lược đồ. Luôn sử dụng SQL được tạo của nó làm mẫu nhưng xem qua nó trước khi thực hiện thay đổi (Tôi đã thấy ORM của chúng tôi tạo các chỉ mục dư thừa, sử dụng các loại dữ liệu xấu ... tất cả những thứ xấu đó)
Hãy nhận biết những gì ORM của bạn không thể làm. Django trong một thời gian không hỗ trợ nhóm thông qua ORM, đó là một nỗi đau (vẫn là, hệ thống di sản thú vị!). Vì vậy, nhận thức được các hạn chế của ORM là điều bắt buộc đối với DBA ngay cả khi họ không phải là người viết mã cho ORM
Định kỳ, lấy các bản ghi chậm của bạn, tổng hợp chúng thông qua mysqlslowlog và nhìn vào top 10 hoặc hơn. Về cơ bản, nó sẽ hiển thị cho bạn các truy vấn mất tổng thời gian tổng thể nhất. Một truy vấn chỉ mất trung bình 1 giây nhưng đã chạy 50 nghìn lần trong tháng vừa qua sẽ xuất hiện trên báo cáo tổng hợp đó như ngón tay cái đau;)

Tôi sẽ không nói đi cực đoan như đổ hoàn toàn ORM. Nếu các nhà phát triển của bạn sử dụng ORM không phải là DBA, họ có khả năng viết SQL tệ hoặc tệ hơn ORM. Vì vậy, cuối cùng nó sẽ rơi vào DBA để xem những gì đang diễn ra.

— TechieGurl
nguồn

1

Và xem xét đưa logic rất phức tạp vào một Proc lưu trữ. Các ORM có thể gọi các procs được lưu trữ và đối với logic rất phức tạp, việc thực hiện điều chỉnh một Proc sẽ dễ dàng hơn.

— HLGEM

7

Có một vài điều tôi nhận thấy ngay về một cơ sở dữ liệu kế thừa khác với cơ sở dữ liệu được tạo bởi các ORM như Sequel và ActiveRecord cho Ruby.

Việc sử dụng một khóa chính trong tất cả các bảng được gọi 'id'. Vâng, đó có thể được ghi đè, nhưng idlà mặc định.
Việc sử dụng tên số nhiều cho các bảng.
Việc sử dụng dấu gạch dưới ("snakecase") để phân tách các từ tạo ra tên mô tả của các bảng và trường.
Việc sử dụng _idgắn vào khóa ngoại: Bố cục thường như thế nào referenced_table_id.

Tôi đã viết SQL bằng tay trong nhiều năm vì tôi không tin tưởng ORM, nhưng trong hai hoặc ba lần trước tôi đã bắt đầu sử dụng hai ORM đã đề cập trước đó và rất ấn tượng về việc chúng tích hợp tốt với cơ sở dữ liệu hiện tại như thế nào, và họ có thể giải mã cơ sở dữ liệu tốt như thế nào nếu các quy ước của họ được tuân theo, hoặc tôi dành thời gian để cung cấp cho họ các gợi ý cần thiết để hiểu DB kế thừa.

Tôi không biết có bất kỳ hướng dẫn chung nào để thiết kế các lược đồ để chơi tốt với ORM không, nhưng tôi nghĩ tất cả chúng ta đều có lợi khi có một số tiêu chuẩn. Chắc chắn có thời gian và địa điểm cho một ORM, đặc biệt nếu bạn đang sử dụng ngôn ngữ OO tốt và bạn đang có một lịch trình chặt chẽ.

— người đàn ông
nguồn

1

FYI: có các công cụ để đối phó với sự khác biệt về quy ước đặt tên cho nhiều người lập bản đồ OR. Tôi có một bổ trợ cho Visual Studio, đảm nhiệm việc đó cho Entity Framework và Linq-to-SQL với cách đặt tên dựa trên quy tắc; xem huagati.com/dbmltools để biết thêm chi tiết về điều đó.

— KristoferA

1

Id là một phản mẫu SQL để đặt tên trường id và không nên được sử dụng.

— HLGEM

Quan tâm giải thích tại sao? Làm thế nào để chúng ta xử lý các mối quan hệ giữa các bảng khi chúng ta cần thực hiện tra cứu như một-nhiều và nhiều-một? Trong các ORM tôi sử dụng không sử dụng ID chắc chắn sẽ đi ngược lại dòng chảy.

— Tin Man

2

Nó phụ thuộc (:)) một chút vào những gì OR mapper bạn đang sử dụng, vì vậy hãy dành thời gian nghiên cứu những tính năng db của trình ánh xạ OR trong hỗ trợ câu hỏi / không hỗ trợ.

Ví dụ: trình ánh xạ OR của Microsoft không hỗ trợ tất cả các kiểu dữ liệu tích hợp của SQL Server, không hỗ trợ một số tính năng TSQL mới hơn / nâng cao (truy vấn đệ quy, gợi ý tối ưu hóa v.v.

Về lý thuyết , một trình ánh xạ OR tốt phải đủ linh hoạt để vượt qua (và cho phép bạn ánh xạ) một lược đồ cơ sở dữ liệu quan hệ được thiết kế tốt thành một mô hình đối tượng tốt. Trong thực tế, chúng ta vẫn còn một chút để đi trước khi tất cả các mảnh ghép được đưa ra; mặc dù nhiều trình ánh xạ OR hỗ trợ ánh xạ nâng cao nhưng nó thường phải trả giá bằng các truy vấn phức tạp và các vấn đề về hiệu năng.

Để có hiệu suất db tốt (và để duy trì sự tỉnh táo của dba :)) bạn vẫn nên tuân theo các thực tiễn tốt nhất khi nói đến thiết kế lược đồ db; bình thường hóa đầu tiên và không chuẩn hóa khi [/ nếu] cần thiết. Về phía mã, đừng quá nhiệt tình với mô hình đối tượng của bạn ; ngay cả khi trình ánh xạ OR hỗ trợ các mô hình và thực thể kế thừa phức tạp hợp nhất nhiều bảng với nhau, đây cũng là những lĩnh vực mà bạn có nguy cơ gặp rắc rối với các truy vấn quá phức tạp đánh vào cơ sở dữ liệu, v.v. Hồ sơ, hồ sơ, hồ sơ và không chỉ lấy ORM tạo truy vấn được cấp. Hãy nhớ rằng các truy vấn được tạo bởi trình ánh xạ thường có thể được điều chỉnh giống như các truy vấn SQL thông thường và hai truy vấn tương đương về chức năng ở phía đối tượng (ví dụ: truy vấn linq) đôi khi có thể dẫn đến các truy vấn SQL khác nhau.

— KristoferA
nguồn