Khi không sử dụng ORM và thích các thủ tục được lưu trữ?

13

Tôi đang sử dụng PetaPoco micro-ORM. Thực sự rất dễ dàng và an toàn để làm việc với cơ sở dữ liệu bằng các công cụ ORM, nhưng điều duy nhất tôi ghét là mã bổ sung. Tôi đã sử dụng để đặt hầu hết các mã trong cơ sở dữ liệu và sử dụng tất cả các tính năng RDBMS như Thủ tục lưu trữ, Triggers, v.v., nó được xây dựng để xử lý tốt hơn.

Tôi muốn biết khi nào không sử dụng ORM trên Thủ tục lưu trữ / Kích hoạt và ngược lại.

orm rdbms stored-procedures

— RPK
nguồn

6

Cá nhân, vấn đề của tôi với các trình kích hoạt (đặc biệt là không áp dụng cho các thủ tục được lưu trữ) là họ cố gắng "đoán" những gì "hành động kinh doanh" đã xảy ra từ cách dữ liệu trên DB bị thao túng. Nếu bạn sửa đổi cột GIÁ trong bảng "BÀI VIẾT", thì bạn không thực sự biết tại sao lại như vậy. Là người dùng chỉ cần sửa một giá trị sai? Đó có phải là một đánh dấu xuống? Đó có phải là một đề nghị đặc biệt chỉ kéo dài trong một ngày? Triggers phải đoán tất cả những điều đó.

— Joachim Sauer

16

Các ORM (ánh xạ quan hệ đối tượng) không loại trừ lẫn nhau với các thủ tục được lưu trữ. Hầu hết các ORM có thể sử dụng các thủ tục được lưu trữ. Hầu hết các ORM tạo Thủ tục lưu trữ nếu bạn chọn. Vì vậy, vấn đề không phải là hoặc.

Các ORM có thể tạo SQL không được chấp nhận (về hiệu suất) và đôi khi bạn có thể muốn ghi đè SQL đó bằng SQL thủ công. Một trong những cách để thực hiện điều này là bằng cách sử dụng SP (thủ tục được lưu trữ).

Trong DotNet, Không sử dụng các quy trình được lưu trữ nếu:

Nếu bạn không quen thuộc với các thủ tục được lưu trữ (không phải trường hợp của bạn, nhưng được bao gồm để hoàn thiện).
Nếu bạn không muốn giới thiệu một lớp phức tạp và đa dạng hóa cho dự án của bạn.
Bạn đang tạo một ứng dụng nên hoạt động với các cơ sở dữ liệu khác nhau hoặc sẽ phải được nhân rộng trên một số máy chủ cơ sở dữ liệu (hạn chế cuối cùng này chỉ có thể áp dụng cho một số cơ sở dữ liệu).

Lưu ý rằng các kích hoạt không được so sánh với ORM. Kích hoạt làm các chức năng tốt hơn không có trong mã ứng dụng của bạn (chẳng hạn như ghi nhật ký hoặc đồng bộ hóa dữ liệu trên cơ sở dữ liệu).

Một số người thích sử dụng Quy trình được lưu trữ hơn SQL trong mã vì các lý do khác nhau, chẳng hạn như bảo mật (ví dụ để ngăn chặn việc tiêm SQL) và cho tốc độ được yêu cầu của họ. Tuy nhiên, điều này có phần gây tranh cãi và cần thảo luận chi tiết.

Nếu ORM của bạn không thể tạo Thủ tục lưu trữ và bạn phải viết một hệ thống lớn, thì bạn cần phải cân nhắc mã hóa thêm dựa trên trường hợp của bạn.

— Không có cơ hội
nguồn

2

Tôi tin rằng đối số bảo mật không liên quan đến SQL SQL, mà là các quyền (nghĩa là đơn giản để quản lý các quyền đối với một thủ tục được lưu trữ cụ thể cho người dùng có quyền truy cập vào cơ sở dữ liệu, nhưng quản lý các quyền đó trên bảng, cột và hàng khó hơn hoặc không thể). Tuy nhiên, các đối số bảo mật vẫn còn gây tranh cãi.

— Arseni Mourzenko

@MainMa, cảm ơn bình luận của bạn. Tôi hiểu rằng khi sử dụng SP, người ta có thể giảm nguy cơ tiêm SQL bằng cách sử dụng quy trình được lưu trữ được tham số hóa với các tham số được nhúng như bài viết này gợi ý: palepage.plynt.com/issues/2006Jun/injection-stored-procedures

— NoChance

2

Các thủ tục được lưu trữ hầu như không có tác động đến lỗ hổng đối với các cuộc tấn công tiêm sql. Huyền thoại cũ chết cứng.

— Rig

@Rig 1, cảm ơn bạn đã bình luận, tôi muốn tìm hiểu thêm về những gì bạn nghĩ về điều này. Sự hiểu biết của tôi xuất phát từ văn bản này (ít nhất): "Bạn có thể ngăn chặn các cuộc tấn công tiêm nhiễm SQL Server bằng cách sử dụng các thủ tục được lưu trữ và các lệnh được tham số hóa, tránh SQL động và hạn chế quyền đối với tất cả người dùng." xuất hiện trong msdn.microsoft.com/en-us/l

— Library / bb669057.aspx

@EmmadKareem sql tham số là một bước tiến lớn trong việc làm cho nó an toàn. Tôi nghĩ rằng anh chàng này tạo ra một trường hợp hợp lý pal con.plynt.com/issues/2006Jun/injection-stored-procedures . Một tìm kiếm trên đó sẽ "Lưu trữ thủ tục SQL tiêm" sẽ cho ra rất nhiều lượt truy cập. Luôn luôn tốt để vệ sinh đầu vào của bạn và rất nhiều nền tảng cung cấp một cách tích hợp để làm điều đó một cách hợp lý.

— Rig

13

Các ORM thường cho rằng cơ sở dữ liệu tồn tại để phục vụ ORM. Nhưng thông thường cơ sở dữ liệu tồn tại để phục vụ công ty, có thể có hàng trăm và hàng trăm ứng dụng được viết bằng nhiều ngôn ngữ.

Nhưng đó chỉ là trường hợp "ORM so với thủ tục được lưu trữ" nếu bạn đang sử dụng ORM không thể gọi thủ tục được lưu trữ. Mặt khác, đó là một trường hợp quyết định nơi mã hóa logic kinh doanh.

Bất cứ nơi nào bạn viết mã logic nghiệp vụ, công việc của nó là đảm bảo cơ sở dữ liệu thay đổi từ trạng thái nhất quán này sang trạng thái nhất quán khác bất kể ứng dụng nào thực hiện thay đổi . Vì vậy, bạn thực sự chỉ có hai lựa chọn thực tế - mã hóa nó một lần trong cơ sở dữ liệu hoặc mã hóa nó một lần trong lớp truy cập dữ liệu "không thể xuyên thủng".

Cảnh giác với giao diện dòng lệnh dbms nếu bạn sử dụng DAL "không thể xuyên thủng".

— Mike Sherrill 'Nhớ lại mèo'
nguồn

4

Tôi đã gặp phải nhiều trường hợp trong đó các SP và bộ kích hoạt cũ phải được sử dụng với các ứng dụng mới vì các ứng dụng cũ. Ưu điểm là logic kinh doanh này chỉ phải được duy trì ở một nơi.

— jfrankcarr

Tôi chắc chắn không phủ nhận rằng "một cơ sở dữ liệu để phục vụ tất cả" đã được sử dụng, nhưng nó chủ yếu là quá khứ bởi vì bảo trì trở thành địa ngục thuần túy, đặc biệt là khi nhiều ứng dụng cần duy trì phiên bản procs lưu trữ của riêng chúng. Có cơ sở dữ liệu tồn tại để phục vụ ứng dụng sở hữu nó là một cách tiếp cận hiện đại hơn nhiều vì nó thực thi việc ghép lỏng hơn giữa các ứng dụng và dịch vụ.

— Flater

-1

Truy vấn đơn giản -> ORM

Truy vấn phức tạp -> Thủ tục lưu trữ

— Đêm tối
nguồn

3

Trường hợp nào tách biệt phức tạp khỏi Truy vấn đơn giản,

— Độc lập

-2

Kích hoạt nên được sử dụng như bất biến của hồ sơ hoặc bao gồm các quy tắc kinh doanh quan trọng, IMHO.

Các vấn đề của orms:

Bạn nên đặt quyền cho mỗi bảng, không phải cho mỗi "Hành động" (ý tôi là SP)
Để thay đổi logic của giải pháp của bạn, bạn cần thay đổi mã bên trong ứng dụng của mình và sau đó phân phối lại qua mạng cho khách hàng

— Yuriy Vikulov
nguồn

-5

Không đồng ý. Truy vấn ORM chỉ đơn giản hơn nếu bạn biết ORM tốt hơn bạn biết SQL. ORM dẫn đến nhiều mã hơn, rất khó để duy trì IMO. Những người duy nhất được hưởng lợi từ ORM là các cổ đông của công ty bán ORM (ví dụ: Microsoft).

— ma
nguồn

1

khá đáng tiếc rằng ý kiến thể hiện trong câu trả lời này không được hỗ trợ bởi các tài liệu tham khảo cũng như kinh nghiệm. Kết quả là, một người đọc có thể vấp phải một yêu cầu "nghịch đảo" như các thủ tục được lưu trữ chỉ có lợi cho các nhà cung cấp DB . Làm cho người ta nhận ra lý do tại sao hướng dẫn trong Câu hỏi thực tế có Câu trả lời : "câu hỏi thực sự có câu trả lời , không phải là mục hoặc ý tưởng hoặc ý kiến ... "

— gnat