Tham gia là dành cho những người lười biếng?

Gần đây tôi đã có một cuộc thảo luận với một nhà phát triển khác, người đã tuyên bố với tôi rằng THAM GIA (SQL) là vô dụng. Điều này đúng về mặt kỹ thuật nhưng ông nói thêm rằng việc sử dụng các phép nối ít hiệu quả hơn so với việc thực hiện một số yêu cầu và bảng liên kết trong mã (C # hoặc Java).

Đối với anh ta tham gia là dành cho những người lười biếng không quan tâm đến hiệu suất. Điều này có đúng không? Chúng ta có nên tránh sử dụng tham gia?

Không, chúng ta nên tránh các nhà phát triển nắm giữ những ý kiến ​​cực kỳ sai lầm như vậy.

Trong nhiều trường hợp, tham gia cơ sở dữ liệu nhanh hơn nhiều lần so với mọi thứ được thực hiện thông qua máy khách, vì nó tránh được các vòng tròn DB và DB có thể sử dụng các chỉ mục để thực hiện phép nối.

Ngoài đỉnh đầu, tôi thậm chí không thể tưởng tượng được một kịch bản trong đó một phép nối được sử dụng chính xác sẽ chậm hơn so với thao tác phía máy khách tương đương.

Chỉnh sửa: Có một số trường hợp hiếm hoi trong đó mã máy khách tùy chỉnh có thể thực hiện mọi việc hiệu quả hơn so với tham gia DB đơn giản (xem nhận xét của meriton). Nhưng đây là rất nhiều ngoại lệ.

Nghe có vẻ như đồng nghiệp của bạn sẽ làm tốt với cơ sở dữ liệu không có dữ liệu hoặc kho lưu trữ khóa-giá trị. Đó là những công cụ rất tốt và phù hợp cho nhiều vấn đề.

Tuy nhiên, một cơ sở dữ liệu quan hệ được tối ưu hóa rất nhiều để làm việc với các bộ. Có rất nhiều, rất nhiều cách để truy vấn dữ liệu dựa trên tham gia có bao la hiệu quả hơn rất nhiều chuyến đi vòng. Đây là nơi mà tính đa năng của một rdbms đến từ. Bạn cũng có thể đạt được điều tương tự trong một cửa hàng nosql, nhưng cuối cùng bạn thường xây dựng một cấu trúc riêng phù hợp với từng tính chất truy vấn khác nhau.

Tóm lại: Tôi không đồng ý. Trong một RDBMS, các phép nối là cơ bản . Nếu bạn không sử dụng chúng, bạn sẽ không sử dụng nó như một RDBMS.

Vâng, anh ấy sai trong trường hợp chung.

Cơ sở dữ liệu có thể tối ưu hóa bằng nhiều phương pháp khác nhau, được trợ giúp bởi các gợi ý tối ưu hóa, chỉ mục bảng, mối quan hệ khóa ngoài và có thể thông tin cụ thể của nhà cung cấp cơ sở dữ liệu khác.

Không, bạn không nên.

Cơ sở dữ liệu được thiết kế đặc biệt để thao tác các bộ dữ liệu (rõ ràng ....). Do đó, họ cực kỳ hiệu quả trong việc này. Bằng cách thực hiện những gì về cơ bản là tham gia thủ công vào mã riêng của mình, anh ta đang cố gắng đảm nhận vai trò của một thứ được thiết kế riêng cho công việc. Cơ hội mã của anh ta có hiệu quả như trong cơ sở dữ liệu là rất xa.

Như một bên, không tham gia, điểm quan trọng trong việc sử dụng cơ sở dữ liệu là gì? anh ta cũng có thể chỉ sử dụng các tập tin văn bản.

Nếu "lười biếng" được định nghĩa là những người muốn viết ít mã hơn, thì tôi đồng ý. Nếu "lười biếng" được định nghĩa là những người muốn có công cụ làm những gì họ giỏi, tôi đồng ý. Vì vậy, nếu anh ta chỉ đồng ý với Larry Wall (liên quan đến các thuộc tính của các lập trình viên giỏi), thì tôi đồng ý với anh ta.

Ummm, tham gia là cách cơ sở dữ liệu quan hệ liên kết các bảng với nhau. Tôi không chắc anh ấy đang làm gì.

Làm thế nào để thực hiện một số cuộc gọi đến cơ sở dữ liệu hiệu quả hơn một cuộc gọi? Cộng với động cơ sql được tối ưu hóa để làm điều này.

Có thể đồng nghiệp của bạn quá lười học SQL.

Vâng, bạn nên.

Và bạn nên sử dụng C ++ thay vì C # vì hiệu suất. C # dành cho người lười biếng.

Không không không. Bạn nên sử dụng C thay vì C ++ vì hiệu suất. C ++ dành cho những người lười biếng.

Không không không. Bạn nên sử dụng lắp ráp thay vì C vì hiệu suất. C dành cho người lười biếng.

Vâng, tôi đang nói đùa. bạn có thể tạo các chương trình nhanh hơn mà không cần tham gia và bạn có thể tạo các chương trình sử dụng ít bộ nhớ hơn mà không cần tham gia. NHƯNG trong nhiều trường hợp, thời gian phát triển của bạn quan trọng hơn thời gian và bộ nhớ CPU. Từ bỏ một chút hiệu suất và tận hưởng cuộc sống của bạn. Đừng lãng phí thời gian của bạn cho hiệu suất nhỏ. Và nói với anh ta "Tại sao bạn không làm một đường cao tốc thẳng từ nơi bạn đến văn phòng của bạn?"

"Đây là kỹ thuật đúng" - tương tự, cơ sở dữ liệu SQL là vô ích: điểm nào trong việc sử dụng một khi bạn có thể nhận được kết quả tương tự bằng cách sử dụng một loạt các tệp CSV và tương quan chúng trong mã? Heck, bất kỳ sự trừu tượng nào là dành cho những người lười biếng, hãy quay lại lập trình bằng mã máy ngay trên phần cứng! ;)

Ngoài ra, khẳng định của anh ta là không đúng sự thật trong tất cả các trường hợp ngoại trừ nhất: RDBMS được tối ưu hóa mạnh mẽ để làm cho THAM GIA nhanh chóng . Hệ thống quản lý cơ sở dữ liệu quan hệ, phải không?

Công ty cuối cùng tôi làm việc cũng không sử dụng SQL tham gia. Thay vào đó, họ chuyển công việc này sang lớp ứng dụng được thiết kế theo tỷ lệ theo chiều ngang. Lý do căn bản của thiết kế này là để tránh làm việc ở lớp cơ sở dữ liệu. Nó thường là cơ sở dữ liệu trở thành nút cổ chai. Nó dễ dàng để nhân rộng lớp ứng dụng hơn cơ sở dữ liệu. Có thể có những lý do khác. Nhưng đây là cái mà tôi có thể nhớ lại bây giờ.

Có, tôi đồng ý rằng các phép nối được thực hiện ở lớp ứng dụng là không hiệu quả so với các phép nối được thực hiện bởi cơ sở dữ liệu. Truyền thông mạng nhiều hơn.

Xin lưu ý rằng tôi không chịu khó tránh khỏi việc tham gia SQL.

Nếu không tham gia, làm thế nào bạn có thể liên kết các mục đặt hàng với các đơn đặt hàng? Đó là toàn bộ điểm của một hệ thống quản lý cơ sở dữ liệu quan hệ. Không tham gia thì không có dữ liệu quan hệ và bạn cũng có thể sử dụng các tệp văn bản để xử lý dữ liệu.

Có vẻ như anh ta không hiểu khái niệm này nên anh ta cố gắng làm cho có vẻ như họ vô dụng. Anh ấy là kiểu người nghĩ excel là một ứng dụng cơ sở dữ liệu. Tát anh ta một cách ngớ ngẩn và bảo anh ta đọc thêm về cơ sở dữ liệu. Tạo nhiều kết nối và kéo dữ liệu và hợp nhất dữ liệu qua C # là cách làm sai.

Tôi không hiểu logic của câu lệnh "tham gia vào SQL là vô ích". Có hữu ích để lọc và giới hạn dữ liệu trước khi làm việc không? Như những người trả lời khác của bạn đã tuyên bố đây là những gì công cụ cơ sở dữ liệu làm, nó nên là những gì họ giỏi.

Có lẽ một lập trình viên lười biếng sẽ gắn bó với các công nghệ mà họ quen thuộc và tránh những khả năng khác vì những lý do phi kỹ thuật.

Tôi để nó cho bạn quyết định.

Hãy xem xét một ví dụ: bảng có bản ghi hóa đơn và bảng có liên quan với bản ghi chi tiết đơn hàng hóa đơn. Hãy xem xét mã giả của khách hàng:

for each (invoice in invoices)
    let invoiceLines = FindLinesFor(invoice)
...

Nếu bạn có 100.000 hóa đơn với 10 dòng mỗi mã, mã này sẽ tra cứu 10 dòng hóa đơn từ bảng 1 triệu và nó sẽ thực hiện 100.000 lần. Khi kích thước bảng tăng lên, số lượng thao tác chọn sẽ tăng lên, và chi phí của mỗi thao tác chọn sẽ tăng.

Trở thành máy tính nhanh, bạn có thể không nhận thấy sự khác biệt về hiệu suất giữa hai cách tiếp cận nếu bạn có vài nghìn bản ghi hoặc ít hơn. Bởi vì chi phí tăng nhiều hơn tuyến tính, khi số lượng hồ sơ tăng (lên tới hàng triệu, giả sử), bạn sẽ bắt đầu nhận thấy sự khác biệt và sự khác biệt sẽ trở nên khó chấp nhận hơn khi kích thước của tập dữ liệu tăng lên.

Việc tham gia, tuy nhiên. sẽ sử dụng các chỉ mục của bảng và hợp nhất hai tập dữ liệu. Điều này có nghĩa là bạn đang quét bảng thứ hai một cách hiệu quả thay vì truy cập ngẫu nhiên N lần. Nếu có khóa ngoại được xác định, cơ sở dữ liệu đã có các liên kết giữa các bản ghi liên quan được lưu trữ bên trong.

Hãy tưởng tượng làm điều này chính mình. Bạn có một danh sách theo thứ tự chữ cái của học sinh và một cuốn sổ ghi chép với tất cả các báo cáo điểm của học sinh (một trang cho mỗi lớp). Sổ ghi chép được sắp xếp theo thứ tự theo tên của học sinh, theo thứ tự giống như danh sách. Làm thế nào bạn muốn tiến hành?

1. Đọc tên từ danh sách.
2. Mở vở ra.
3. Tìm tên của học sinh.
4. Đọc điểm của học sinh, lật trang cho đến khi bạn đến được học sinh tiếp theo hoặc trang cuối cùng.
5. Đóng vở.
6. Nói lại.

Hoặc là:

1. Mở cuốn sổ ra trang đầu tiên.
2. Đọc tên từ danh sách.
3. Đọc bất kỳ điểm nào cho tên đó từ sổ ghi chép.
4. Lặp lại các bước 2-3 cho đến khi bạn kết thúc
5. Đóng vở.

Âm thanh như một trường hợp kinh điển của " Tôi có thể viết nó tốt hơn ." Nói cách khác, anh ta đang nhìn thấy thứ gì đó mà anh ta thấy là một nỗi đau ở cổ (viết một loạt các phép nối bằng SQL) và nói "Tôi chắc chắn rằng tôi có thể viết nó tốt hơn và có hiệu suất tốt hơn." Bạn nên hỏi anh ta nếu anh ta là một) thông minh hơn và b) có học thức hơn người điển hình nằm sâu trong mã tối ưu hóa Máy chủ Oracle hoặc SQL. Odds là anh ấy không.

Anh ấy chắc chắn là sai. Mặc dù có những ưu điểm nhất định đối với thao tác dữ liệu trong các ngôn ngữ như C # hoặc Java, các phép nối nhanh nhất trong cơ sở dữ liệu do bản chất của chính SQL.

SQL tiếp tục chi tiết các số liệu thống kê liên quan đến dữ liệu và nếu bạn đã tạo các chỉ mục của mình một cách chính xác, có thể nhanh chóng tìm thấy một bản ghi trong vài triệu. Bên cạnh thực tế là tại sao bạn muốn kéo tất cả dữ liệu của mình vào C # để thực hiện tham gia khi bạn có thể thực hiện ngay trên cấp độ cơ sở dữ liệu?

Ưu điểm cho việc sử dụng C # phát huy tác dụng khi bạn cần làm điều gì đó lặp đi lặp lại. Nếu bạn cần thực hiện một số chức năng cho mỗi hàng, có thể nhanh hơn để thực hiện điều đó trong C #, nếu không, việc nối dữ liệu được tối ưu hóa trong DB.

Tôi sẽ nói rằng tôi đã gặp phải trường hợp nhanh hơn phá vỡ truy vấn và thực hiện các phép nối trong mã. Điều đó đang được nói, chỉ với một phiên bản cụ thể của MySQL mà tôi phải làm điều đó. Mọi thứ khác, cơ sở dữ liệu có thể sẽ nhanh hơn (lưu ý rằng bạn có thể phải tối ưu hóa các truy vấn, nhưng nó vẫn sẽ nhanh hơn).

Tôi nghi ngờ anh ta có một cái nhìn hạn chế về những cơ sở dữ liệu nên được sử dụng cho. Một cách tiếp cận để tối đa hóa hiệu suất là đọc toàn bộ cơ sở dữ liệu vào bộ nhớ. Trong tình huống này, bạn có thể có hiệu suất tốt hơn và bạn có thể muốn thực hiện tham gia nếu bộ nhớ cho hiệu quả. Tuy nhiên, điều này không thực sự sử dụng cơ sở dữ liệu, như một cơ sở dữ liệu IMHO.

Không, không chỉ các phép nối được tối ưu hóa tốt hơn trong mã cơ sở dữ liệu mà ad-hoc C # / Java; nhưng thường có thể áp dụng một số kỹ thuật lọc, mang lại hiệu suất cao hơn.

Ông đã sai, tham gia là những gì lập trình viên có thẩm quyền sử dụng. Có thể có một vài trường hợp giới hạn trong đó phương pháp được đề xuất của anh ta hiệu quả hơn (và có lẽ tôi sẽ sử dụng cơ sở dữ liệu Tài liệu) nhưng tôi không thể thấy nó nếu bạn có bất kỳ lượng dữ liệu lừa đảo nào. Ví dụ: lấy truy vấn này:

select t1.field1 
from table1 t1
join table2 t2 
    on t1.id = t2.id
where t1.field2 = 'test'

Giả sử bạn có 10 triệu bản ghi trong bảng1 và 1 triệu bản ghi trong bảng2. Giả sử 9 triệu bản ghi trong bảng 1 đáp ứng mệnh đề where. Giả sử chỉ có 15 người trong số họ ở trong bảng2. Bạn có thể chạy câu lệnh sql này, nếu được lập chỉ mục đúng sẽ mất mili giây và trả về 15 bản ghi trên mạng chỉ với 1 cột dữ liệu. Hoặc bạn có thể gửi mười triệu bản ghi với 2 cột dữ liệu và gửi riêng 1 triệu bản ghi khác với một cột dữ liệu trên mạng và kết hợp chúng trên máy chủ web.

Hoặc tất nhiên bạn có thể giữ toàn bộ nội dung của cơ sở dữ liệu trên máy chủ web mọi lúc, điều này thật ngớ ngẩn nếu bạn có nhiều hơn một lượng dữ liệu và dữ liệu không đáng kể liên tục thay đổi. Nếu bạn không cần những phẩm chất của cơ sở dữ liệu quan hệ thì đừng sử dụng cơ sở dữ liệu. Nhưng nếu bạn làm, sau đó sử dụng nó một cách chính xác.

Tôi đã nghe cuộc tranh luận này khá thường xuyên trong suốt sự nghiệp là một nhà phát triển phần mềm. Hầu như mọi lúc mọi nơi đều được tuyên bố, anh chàng đưa ra yêu sách không có nhiều kiến ​​thức về các hệ thống cơ sở dữ liệu quan hệ, cách họ làm việc và cách sử dụng các hệ thống như vậy.

Có, khi sử dụng không chính xác , tham gia dường như vô dụng hoặc thậm chí nguy hiểm. Nhưng khi được sử dụng đúng cách, có rất nhiều tiềm năng để triển khai cơ sở dữ liệu để thực hiện tối ưu hóa và "giúp" nhà phát triển truy xuất kết quả chính xác một cách hiệu quả nhất.

Đừng quên rằng việc JOINbạn nói với cơ sở dữ liệu về cách bạn mong đợi các phần dữ liệu có liên quan với nhau và do đó cung cấp cho cơ sở dữ liệu nhiều thông tin hơn về những gì bạn đang cố gắng thực hiện và do đó làm cho nó có thể phù hợp hơn với nhu cầu của bạn.

Vì vậy, câu trả lời chắc chắn là: Không, hoàn toàn JOINSkhông vô dụng!

Điều này là "đúng về mặt kỹ thuật" chỉ trong một trường hợp không được sử dụng thường xuyên trong các ứng dụng (khi tất cả các hàng của tất cả các bảng trong (các) phép nối được trả về bởi truy vấn). Trong hầu hết các truy vấn, chỉ một phần của các hàng của mỗi bảng được trả về. Công cụ cơ sở dữ liệu thường sử dụng các chỉ mục để loại bỏ các hàng không mong muốn, đôi khi thậm chí không đọc hàng thực tế vì nó có thể sử dụng các giá trị được lưu trữ trong các chỉ mục. Công cụ cơ sở dữ liệu được viết bằng C, C ++, v.v. và ít nhất là hiệu quả như mã được viết bởi nhà phát triển.

Trừ khi tôi hiểu lầm nghiêm trọng, logic trong câu hỏi rất thiếu sót

Nếu có 20 hàng trong B cho mỗi A, thì 1000 hàng trong A ngụ ý 20k hàng trong B. Không thể chỉ có 100 hàng trong B trừ khi có nhiều bảng "AB" với 20k hàng có chứa ánh xạ .

Vì vậy, để có được tất cả thông tin về 20 trong số 100 hàng B ánh xạ cho mỗi hàng A bạn cũng bảng AB. Vì vậy, đây sẽ là:

• 3 bộ kết quả gồm 100, 1000 và 20 nghìn hàng và một khách hàng THAM GIA
• một kết quả A-AB-B được THAM GIA duy nhất với 20k hàng

Vì vậy, "THAM GIA" trong máy khách sẽ thêm bất kỳ giá trị nào khi bạn kiểm tra dữ liệu. Không phải đó không phải là một ý tưởng tồi. Nếu tôi đang lấy một đối tượng từ cơ sở dữ liệu thì có lẽ sẽ có ý nghĩa hơn khi chia nó thành các tập kết quả riêng biệt. Đối với một cuộc gọi loại báo cáo, tôi sẽ làm phẳng nó thành một cuộc gọi gần như luôn luôn.

Trong mọi trường hợp, tôi muốn nói rằng hầu như không có sự tham gia chéo nào của cường độ này. Đó là một ví dụ nghèo nàn.

Bạn phải THAM GIA ở đâu đó và đó là những gì RDBMS giỏi. Tôi không muốn làm việc với bất kỳ khỉ mã khách hàng nào nghĩ rằng họ có thể làm tốt hơn.

Suy nghĩ lại:

Để tham gia vào máy khách cần có các đối tượng liên tục như DataTables (trong .net). Nếu bạn có một kết quả được làm phẳng, nó có thể được sử dụng thông qua một cái gì đó nhẹ hơn như DataReader. Khối lượng lớn = nhiều tài nguyên khách hàng được sử dụng để tránh cơ sở dữ liệu THAM GIA.