Mysql VIEWS so với truy vấn PHP

Question

Tôi đang làm việc trên một ứng dụng web có liên quan đến việc tạo danh sách Nhà hàng trong các danh sách khác nhau như "Joe phải ghé thăm địa điểm". Bây giờ cho mỗi nhà hàng và danh sách, tôi có hiển thị trên trang web này sẽ tính

• Tính phổ biến của một nhà hàng
• phổ biến của một danh sách
• Số danh sách một nhà hàng có mặt trong

Hiện nay Tôi đang sử dụng các câu lệnh MySQL trong PHP cho việc này nhưng lập kế hoạch chuyển sang MySQL VIEWS và làm một câu lệnh chọn đơn giản trong PHP ...

câu hỏi của tôi là, Lợi thế/bất lợi của việc sử dụng VIEWS khi viết các truy vấn sql trong PHP là gì?

Answer 1

Sử dụng chế độ xem thêm mức độ trừu tượng trừu tượng: sau này bạn có thể thay đổi cấu trúc của bảng và bạn sẽ không phải thay đổi mã hiển thị thông tin về danh sách. tuy nhiên, định nghĩa chế độ xem có thể thay đổi).

Sự khác biệt chính là lượt xem được cập nhật sau mỗi lần chèn, sao cho dữ liệu "sẵn sàng" bất cứ khi nào bạn truy vấn chế độ xem, trong khi sử dụng truy vấn tùy chỉnh của bạn sẽ có MySQL tính toán mọi thứ mỗi lần (có một số bộ nhớ đệm, tất nhiên).

Điểm mấu chốt ở đây là nếu danh sách của bạn được cập nhật ít hơn so với khi chúng được xem, bạn sẽ thấy một số lợi ích về hiệu suất khi sử dụng chế độ xem.

Answer 2

Nếu các bảng bạn đang cố gắng xem không bị thay đổi thường xuyên, chắc chắn bạn đạt được hiệu suất, vì bạn chỉ đang chọn đơn giản từ dữ liệu đã chuẩn bị. Nhưng nhận thức được thực tế, quan điểm đó không phải là thứ được tạo ra "một lần và mãi mãi" - mọi thay đổi của nội dung của một trong các bảng sẽ làm cho cơ sở dữ liệu làm "xem làm mới", do đó truy vấn khác (truy vấn bạn đang xem từ) phải được gọi là taki vào các thay đổi tài khoản đã được thực hiện. Để tổng hợp:

Thay đổi không thường xuyên? Hiệu suất. Thay đổi thường xuyên/liên tục (cộng đồng thêm, nhận xét, xếp hạng nhà hàng của bạn) - tốt hơn là truy vấn bằng SQL.

Answer 3

câu trả lời hoàn chỉnh của tôi sẽ phụ thuộc vào một vài điều (từ quan điểm của ứng dụng của bạn):

• làm bạn có kế hoạch cho phép người dùng tạo và chia sẻ danh sách như vậy?
• người dùng có thể tạo danh sách dưới bất kỳ hình thức nào hay chỉ bằng cách cắm giá trị vào mẫu truy vấn hiện tại?

Giả sử bạn có một vài danh sách được xác định trước để hiển thị:

Sử dụng quan điểm cung cấp một vài ưu điểm:

• mã của bạn sẽ sạch hơn
• truy vấn để tạo các khung nhìn sẽ không phải được phân tích mỗi lần bởi mysql.

Tôi không chắc chắn về điều này: Tôi không nghĩ rằng mysql lưu trữ lượt xem như Tomasz gợi ý - Tôi không cho rằng lượt xem chứa "dữ liệu đã được tạo trước".

Một bất lợi là logic liên quan đến việc tạo danh sách đi vào cơ sở dữ liệu thay vì sống trong mã PHP của bạn - điều tôi rất không thích. Trong cơ sở dữ liệu thế giới của tôi là cho dữ liệu, và mã là cho logic.

Chúc mừng

Answer 4

Câu hỏi ban đầu là về ưu và khuyết điểm nhưng không thấy nhiều bất lợi trong câu trả lời cho đến thời điểm này.

Không phải là một bất lợi của quan điểm mà họ có thể cung cấp cho bạn sự thoải mái giả khi chạy một truy vấn đơn giản? Ví dụ, SELECT tên người dùng TỪ myview WHERE id = '1' Điều đó có vẻ đơn giản, nhưng nếu "myview" là một SELECT thực sự phức tạp ... Có lẽ thậm chí được xây dựng trên quan điểm khác? Bạn sẽ có một truy vấn đơn giản, trong nền, mất nhiều công việc hơn là nếu bạn đã viết truy vấn của mình từ đầu.

Tôi đã thử nghiệm với lượt xem và mặc dù lợi ích, chưa được bán hết. Tôi muốn được nghe những gì người khác nhận thấy về những bất lợi của về số lượt xem của Chế độ xem, thay vì chỉ là dòng bên về lý do khiến lượt xem rất tuyệt vời. Có thể vẫn thực hiện chuyển đổi, nhưng muốn hiểu thêm về hiệu suất.

Answer 5

Nhược điểm:

• Trong cơ sở dữ liệu quan điểm của tôi được sử dụng cho lớp dữ liệu và nó không phải là thích hợp để đưa mã số kinh doanh bên trong chúng. Cả hai đều làm giảm khả năng bảo trì và nó mâu thuẫn với việc tách lớp sạch. Điều tương tự cũng áp dụng cho việc bao gồm mã nghiệp vụ và tính toán trong các tập lệnh java của các trang web. Đối với kịch bản java nó thậm chí còn nghiêm trọng hơn vì nó tạo ra các mối đe dọa bảo mật. Kiểm soát nguồn cho mã bên trong cơ sở dữ liệu cũng là một vấn đề khác.

• Bây giờ mã đó nằm bên trong cơ sở dữ liệu, các biến chứng về bảo mật và truy cập (để xem và lưu trữ thủ tục) cũng được thêm vào.

• Di chuyển ứng dụng từ một cơ sở dữ liệu sang một cơ sở dữ liệu khác sẽ khó khăn hơn nhiều (vì ngoài các truy vấn đơn giản, các thủ tục/lượt xem được lưu trữ cũng có thể khác nhau). Nếu cơ sở dữ liệu chỉ là về dữ liệu thì một lớp trừu tượng có thể cho phép thay đổi cơ sở dữ liệu (ít nhất là ở một mức độ nào đó).

Ưu điểm:

• tăng hiệu suất nhẹ (vì dữ liệu không được ra khỏi cơ sở dữ liệu cho chế biến, nó được xử lý ngay trong cơ sở dữ liệu).

• Mã sẽ có vẻ sạch hơn (vì sự bẩn được ẩn bên trong chế độ xem cơ sở dữ liệu, quy trình được lưu trữ, v.v.).