Làm cách nào để xác định thời điểm tạo bảng mới để chứa dữ liệu có thể nhận được từ truy vấn?

Chúng tôi có một bảng thanh toán và các đại lý nhận được hoa hồng cho các khoản thanh toán. Hoa hồng dựa trên một số yếu tố khác nhau, chẳng hạn như mất bao lâu để nhận được khoản thanh toán, do đó, có một số tính toán liên quan khi tìm ra tỷ lệ hoa hồng mà đại lý nhận được, nhưng không có gì phức tạp.

Ví dụ, nó có thể sẽ không bao giờ phức tạp hơn thế này:

SELECT Payments.Amount * CASE 
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 1 THEN Rates.Rate1
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 2 THEN Rates.Rate2
    ELSE Rates.Rate3 END

Sẽ có ý nghĩa khi xây dựng một bảng thứ 2 để giữ dữ liệu này thay vì truy vấn nó bất cứ lúc nào cần thiết? Hoặc tôi chỉ nên giữ các truy vấn thời gian chạy để lấy dữ liệu bất cứ khi nào nó được yêu cầu?

Và quan trọng hơn, các yếu tố sẽ sử dụng khi xác định liệu có nên chạy truy vấn bất cứ khi nào cần dữ liệu hay không, nếu dữ liệu nên được lưu trữ trong một bảng riêng của nó?

Nếu truy vấn được chạy khá ít khi (ví dụ như một báo cáo) thì việc xây dựng bảng trên bay có lẽ tốt hơn ¹ . Nếu truy vấn được chạy thường xuyên và bảng tạm thời được yêu cầu để thực hiện thì bạn có khả năng gặp vấn đề.

• Nếu bảng giá rẻ để xây dựng, sau đó làm nó như một bảng tạm thời. Miễn là cơ sở dữ liệu đủ nhanh, bạn có thể thoát khỏi nó. Tuy nhiên, bạn sẽ cần phải theo dõi hiệu suất.

• Nếu bảng không phải hoàn toàn cập nhật nhưng sẽ là chủ đề của hoạt động báo cáo tương đối thường xuyên hơn là xây dựng lại định kỳ có lẽ là cách tốt nhất để đi.

• Nếu bảng đắt tiền để xây dựng nhưng cần cập nhật, bạn có thể cần quản lý nó dưới dạng cấu trúc không chuẩn hóa, được duy trì dưới dạng xem được lập chỉ mục hoặc thông qua trình kích hoạt. Điều này khá phức tạp và đặt thêm gánh nặng cho các hoạt động ghi.
  
  Trong các trường hợp cực đoan hơn (tức là khối lượng dữ liệu lớn), bạn có thể cần một cách tiếp cận hỗn hợp trong đó dữ liệu lịch sử được truy vấn từ cấu trúc không chuẩn hóa được tối ưu hóa cho hiệu suất và dữ liệu hiện tại được truy vấn từ ứng dụng trực tiếp.
  
  Các trường hợp cực đoan nhất của điều này có thể đưa bạn vào nguồn cấp dữ liệu mart có độ trễ thấp và các giải pháp OLAP lai, do đó, đây là điều phức tạp nhất về độ sâu của lỗ thỏ có thể đi sâu. Tốt nhất nên tránh trừ khi bạn có yêu cầu chính hãng.

Trong trường hợp bạn mô tả ở trên, việc xây dựng lại định kỳ bảng báo cáo nghe có vẻ phù hợp. Nếu bạn cần đóng cửa vào giữa một ngày để chạy các báo cáo thì bạn có thể cung cấp một cơ sở để buộc cập nhật từ ứng dụng. Nếu không thì chạy nó trong một quy trình qua đêm và các đại lý có thể thấy hoa hồng của họ 'như vào nửa đêm của ngày làm việc trước đó.'

¹ select into truy vấn tạo bảng tạm thời khá nhanh trên SQL Server vì các hoạt động chèn được ghi lại tối thiểu.

Vì vậy, để tóm tắt, bạn sử dụng các yếu tố sau để xác định xem bạn có nên có bảng mới cho dữ liệu của mình hay không:

• Tần suất dữ liệu là cần thiết
• Nó đắt như thế nào để có được dữ liệu
• Dữ liệu cần được cập nhật như thế nào

Một vấn đề không được nêu trong câu trả lời được chấp nhận là "bạn có cần giá trị này theo thời gian không" và "công thức có thể thay đổi không".

Ví dụ, hãy xem xét ví dụ về hoa hồng. Nếu hoa hồng được trả, số tiền nên được lưu trữ vì đó là một con số lịch sử của những gì đã thực sự được trả. Cách tính toán hoa hồng có thể thay đổi vào tháng tới (và thường là như vậy) nhưng điều đó sẽ không thay đổi những gì thực sự được trả mà phải được lưu trữ riêng.

Đó là ý tưởng tương tự như lưu trữ giá mà khách hàng thực sự đã trả cho một sản phẩm (sau khi tính toán giảm giá, v.v.) thay vì dựa vào công thức dựa vào bảng giá để làm bất cứ điều gì ngoại trừ tính toán ban đầu vì giá sản phẩm vào tháng tới có thể không giống như giá khi dao kéo thực hiện đơn đặt hàng.

Nếu bạn cần một bản ghi lịch sử về giá trị tại một thời điểm, hãy luôn lưu trữ giá trị đó sau khi sử dụng công thức tính toán bẩm sinh.

Có thể không quan tâm nếu bạn bị khóa vào một cơ sở dữ liệu cụ thể, nhưng MariaDB (tương tự như công việc dựa trên MySQL) có một thứ tuyệt vời gọi là "cột ảo" có thể được tính toán nhanh chóng hoặc được lưu trong bộ nhớ cache trong bộ nhớ thực, nhưng tự động tính lại khi cần. Tôi đã bỏ lỡ chức năng này kể từ khi tôi rời FileMaker Pro cho thế giới SQL nhiều năm trước ...