DataTable Chọn vs LINQ Chọn

Question

Lời khuyên nào về khi DataTable.Select nên được sử dụng so với LINQ Select khi giao dịch với một DataTable trong bộ nhớ?

Tôi thấy cú pháp LINQ dễ dàng hơn và mạnh mẽ hơn, nhưng tôi không chắc liệu có hiệu suất hay các vấn đề khác khiến cho DataTable trở nên thích hợp hơn.

(Tôi đang sử dụng một API của bên thứ ba cung cấp một DataTable đã được điền sẵn từ cơ sở dữ liệu. Tôi cần phải lọc hơn nữa trong bộ nhớ.)

Answer 1

Dựa trên kinh nghiệm cá nhân, tôi cố gắng tránh Datatable.Select. Tôi thấy nó chậm và có một số lỗi lạ.

Lỗi Một (đã được xác nhận và được tài liệu hóa bởi Microsoft) Tôi gặp phải là DataTable.Select không luôn luôn đánh giá VÀ điều kiện chính xác khi có dấu ngoặc đơn trong câu lệnh.

Ví dụ: (Col1> 1) VÀ (Col < 10) không thể trả lại câu trả lời đúng, trong khi Col1> 1 AND Col < 10 sẽ hoạt động chính xác.

Lỗi này không hiển thị trên mọi máy tính. Trong trường hợp của tôi kiểm tra tôi đã sử dụng chạy tốt trên nền tảng phát triển của tôi và mỗi máy tính khách hàng ngoại trừ một. Sau khi tôi phát hiện ra lỗi này, tôi bắt đầu chuyển sang sử dụng LINQ để lựa chọn và nhận thấy sự gia tăng đáng kể tốc độ của các hoạt động.

Lưu ý phụ: Không đi sâu vào các giải thích dài, công ty của tôi không sử dụng cơ sở dữ liệu để lưu trữ dữ liệu. Tất cả hoạt động của chúng tôi với DataTables liên quan đến các bảng bộ nhớ được tải từ các tệp phẳng.Vì vậy, tôi không nói về LINQ 2 SQL, nhưng LINQ to Dataset.

Answer 2

Hmm, bạn đang so sánh bộ dữ liệu với LINQ to SQL ? Nếu bạn đang có, sau đó tôi muốn nói chỉ mương dữ liệu và đi với L2S. DataTable.Select giả sử bạn đã phổ biến dữ liệu có thể đặt dữ liệu. Điều này có thể dẫn đến thiết kế xấu, nơi bạn tải nhiều dữ liệu hơn mức bạn cần, chỉ để lọc trong ứng dụng khách. Nhận SQL Server để làm truy vấn của bạn cho bạn, và làm việc trên resultset nó mang lại cho bạn. L2S sẽ đọc từ cơ sở dữ liệu chỉ khi bạn lặp lại bộ sưu tập, do đó dễ dàng hơn trong việc xây dựng các truy vấn của bạn trước khi nhấn vào cơ sở dữ liệu. LINH to SQL giới thiệu một số chi phí gỡ lỗi bởi vì nó có thể là khó khăn để có được SQL động được tạo ra từ nó (trong khi trong các bộ dữ liệu bạn đang cung cấp SQL ngay từ đầu), nhưng trong hầu hết các tình huống khác, nó còn nhiều hơn nữa thanh lịch. Chức năng deferred loading đặc biệt hữu ích.

Nếu bạn không làm việc với cơ sở dữ liệu, thì tôi vẫn thích LINQ (cụ thể là LINQ to Objects trong trường hợp này) qua tập dữ liệu. Cú pháp này dễ dàng hơn nhiều, và vì không có chuỗi phép thuật (nghĩa là các câu lệnh SQL) thì dễ dàng hơn khi kiểm tra và bạn nhận được cảnh báo thời gian biên dịch cho lỗi chính tả, v.v.

Answer 3

Thậm chí không đề cập đến LINQ, tôi sẽ không sử dụng DataTable. Chọn ở bất kỳ đâu trừ khi tôi hoàn toàn phải làm, vì trong hầu hết các trường hợp, điều đó có nghĩa là thực hiện trong ứng dụng khách thứ gì đó có thể được thực hiện trong cơ sở dữ liệu.

Cập nhật: câu trả lời của tôi ở đây có lẽ hơi bị phóng đại. Có là đôi khi các lý do chính đáng để sử dụng DataTable làm cơ sở dữ liệu trong bộ nhớ nhỏ (hy vọng) giúp giảm thiểu các chuyến đi khứ hồi của khách hàng đến cơ sở dữ liệu.