LINQ to SQL có cung cấp thời gian phản hồi nhanh hơn sử dụng ado.net và oledb không?

Question

LINQ đơn giản hóa lập trình cơ sở dữ liệu không nghi ngờ gì, nhưng nó có nhược điểm không? SQL nội tuyến yêu cầu một giao tiếp với cơ sở dữ liệu theo một cách nào đó để mở cơ sở dữ liệu để tiêm. SQL nội tuyến cũng phải được kiểm tra cú pháp, có một kế hoạch được xây dựng, và sau đó được thực hiện, trong đó có các chu kỳ quý giá. Các thủ tục lưu trữ cũng là một tiêu chuẩn vững chắc trong lập trình ứng dụng cơ sở dữ liệu tuyệt vời. Nhiều lập trình viên tôi biết sử dụng một lớp dữ liệu đơn giản hóa việc phát triển, tuy nhiên, không đến mức mà LINQ làm. Đã đến lúc từ bỏ SP và đi LINQ chưa?

Answer 1

LINQ to SQL thực sự trình bày một số vấn đề hiệu suất đáng báo động trong cơ sở dữ liệu. Về cơ bản, nó tạo ra nhiều kế hoạch thực hiện dựa trên độ dài của tham số bạn đang sử dụng. Tôi đã đăng về nó một lúc trở lại trên blog của tôi LINQ to SQL may cause performance problems.

Bây giờ, có nghĩa là LINQ không có địa điểm? Khó khăn. LINQ chắc chắn có một vị trí trong bộ công cụ phát triển, giống như các thủ tục được lưu trữ. Cuối cùng, bạn muốn sử dụng các thủ tục được lưu trữ khi hiệu năng là hoàn toàn cần thiết và sử dụng một công cụ ORM trong bất kỳ tình huống nào khác.

Theo như SQL nội tuyến, có nhiều cách để thực thi SQL nội tuyến để kế hoạch chỉ được xây dựng một lần và không bao giờ được biên dịch lại. Hầu hết các ORM cần phải quan tâm đến khía cạnh điều chỉnh hiệu năng này và sử dụng các phương pháp này thường là cách an toàn nhất để thực thi câu lệnh SQL của bạn vì nó buộc bạn phải sử dụng các truy vấn được tham số hóa.

Giống như hầu hết các giải pháp cơ sở dữ liệu, câu trả lời đúng tùy thuộc vào vấn đề bạn đang cố giải quyết. Nếu bạn ủng hộ tốc độ phát triển qua hiệu suất cơ sở dữ liệu/ứng dụng, thì sử dụng LINQ hoặc một công cụ DAL/ORM khác là cách tốt nhất để thực hiện. Nếu bạn ủng hộ hiệu suất qua sự phát triển dễ dàng, thì việc sử dụng các thủ tục được lưu trữ và các bộ dữ liệu thuần túy sẽ là đặt cược tốt nhất của bạn. LLBLGen thậm chí còn cung cấp một lớp LINQ to LLBLGen để bạn có thể sử dụng LINQ để truy vấn các đối tượng của LLBLGen và có LLBLGen thực sự xử lý các truy vấn của bạn và tránh một số sự cố của LINQ.

Answer 2

Đây là một hiệu suất do Maximilian Beller điều hành. Theo ông, LINQ chậm hơn nhiều. Read his comprehensive study

Answer 3

Tùy thuộc vào những gì bạn đang làm. LINQ sẽ kém hiệu quả hơn trong thao tác dữ liệu/tập hợp thực tế hơn là một cơ sở dữ liệu thực. Nhưng bạn sẽ tiết kiệm rất nhiều trong việc không phải kết nối với cơ sở dữ liệu qua mạng.

Nếu cơ sở dữ liệu của bạn nằm trên cùng một máy hoặc được chính thức 'kết nối tốt', bạn có thể nên sử dụng nó tốt hơn. Nhưng nếu bạn đang lấy lại một kết quả lớn từ một db từ xa có thể có nghĩa là thời gian truyền đáng kể, hoặc nếu nó là một truy vấn thực sự ngắn sẽ không biện minh cho chi phí, LINQ có thể sẽ tốt hơn.

Answer 4

Nếu bạn quan tâm đến điểm chuẩn, Rico Mariani có excellent 5-part study bao gồm sự khác biệt về chất lượng và định lượng.

Anh ấy có thể là một anh chàng MS, nhưng anh ấy được gọi là hạt hiệu suất - điểm chuẩn của anh ấy là kỹ lưỡng và được suy nghĩ kỹ lưỡng.

Answer 5

Chỉ cần nghĩ về việc thay đổi tên cột - bây giờ thay đổi (n) SP và (x) Số lần xem.

Làm mọi thứ đắt tiền trên cơ sở dữ liệu (như tìm kiếm, sắp xếp, v.v.) và bạn sẽ không nhận thấy sự cố.

Ngoài ra, nếu bạn muốn hiển thị lưới lớn mà không cần phân trang ... thì hãy sử dụng tập dữ liệu - tập dữ liệu đó nhanh hơn.

StackOverflow cũng sử dụng linq2sql - bạn có thấy vấn đề không :)?

Sử dụng ORM - đó là cách để thực hiện hầu hết các ứng dụng.

PS: cũng vậy, về điểm chuẩn vi mô - như .. hãy chọn 10.000 hàng bằng ORM - KHÔNG LÀM VIỆC. Đó không phải là lý do tại sao bạn sử dụng ORM. Nếu bạn muốn chọn 10.000 hàng sử dụng ADO.

Answer 6

Do cấu trúc của LINQ to SQL, không có cách nào có thể là nhanh hơn so với sử dụng SQL thô, truy vấn được tạo tốt của riêng bạn hoặc làm thủ tục được lưu trữ. Những gì LINQ mua bạn không phải là tốc độ mà là loại an toàn và tổ chức; trong ngắn hạn hầu hết các lợi ích mà ORM thường cấp cho bạn.

LINQ to SQL không phải là về tốc độ, đó là về việc xây dựng một hệ thống phần mềm có thể bảo trì hơn. Đó là về tất cả những thứ dành riêng cho các kỹ sư phần mềm và Kiến trúc sư quan tâm, những thứ như ghép nối lỏng lẻo và phân lớp

Điều đó không có nghĩa là bạn không thể xây dựng một số mã thực sự không thể duy trì được với LINQ - không ai ngăn bạn chụp chính mình chân nhưng bạn - nhưng thực hiện đúng, LINQ có thể giúp rất nhiều. Tôi không nói LINQ là một viên đạn bạc, tuy nhiên. Nó có một loạt các vấn đề mà làm cho nó khó sử dụng trong nhiều tình huống doanh nghiệp - đó là lý do tại sao MS cung cấp Entity Framework (ADO.NET 3.0).Tất nhiên, ngay cả điều đó cũng không hoàn hảo khi EF bình chọn gần đây không có niềm tin.

LINQ to SQL hay thậm chí EF tốt hơn SQL thô? Tôi muốn nói một Hells Yeah vang dội. Có các giải pháp nào khác có thể hoạt động tốt hơn không? Có lẽ.

Answer 7

tiền đề cơ bản của bạn là thiếu sót ..

Inline SQL đòi hỏi một để giao tiếp với cơ sở dữ liệu một cách nào đó mở ra cơ sở dữ liệu để tiêm.

Không có. Các giá trị đầu vào do người dùng nhập mã hóa cứng vào một câu lệnh SQL, nhưng bạn cũng có thể làm điều đó với các thủ tục lưu trữ.

Tham số hóa các truy vấn của bạn bảo vệ chống lại các cuộc tấn công tiêm, nhưng SQL nội tuyến có thể được tham số hóa dễ dàng như các thủ tục được lưu trữ.

SQL nội tuyến cũng phải được kiểm tra cú pháp, có kế hoạch được xây dựng và sau đó được thực hiện.

Tất cả Sql (SPs và inline) phải cú pháp kiểm tra và có một kế hoạch xây dựng theo yêu cầu đầu tiên của họ. Sau đó, văn bản chính xác của yêu cầu & kế hoạch thực hiện được lưu vào bộ nhớ cache. Nếu một yêu cầu khác với cùng một văn bản chính xác (không đếm các thông số) được nhận, thì kế hoạch thực thi được lưu trong bộ nhớ cache được sử dụng.

Vì vậy, nếu bạn mã hóa các giá trị thành SQL nội tuyến, văn bản sẽ không khớp và sẽ phải phân tích lại truy vấn. Tuy nhiên, nếu bạn sử dụng các tham số, văn bản của truy vấn sẽ phù hợp và bạn sẽ nhận được một lần truy cập bộ nhớ cache. Trong trường hợp đó, nó sẽ không quan trọng nếu truy vấn trong SQL nội tuyến hoặc SP.

Nói cách khác, vấn đề duy nhất với SQL nội tuyến là dễ dàng thực hiện điều gì đó làm chậm & không an toàn. Nhưng làm cho SQL nội tuyến nhanh chóng & bảo mật không còn hoạt động bằng cách sử dụng SP nữa.

Điều này đưa chúng ta đến LINQ, luôn sử dụng các thông số, ngay cả khi bạn mã hóa cứng các giá trị vào câu lệnh LINQ, làm cho "SQL & bảo mật" nội tuyến SQL tầm thường.

LINQ cũng có lợi thế hơn SP có tất cả mã của bạn ở một chỗ, thay vì nằm rải rác trên hai máy khác nhau.