Bạn đã bao giờ gặp phải một truy vấn mà SQL Server không thể thực thi vì nó tham chiếu quá nhiều bảng?

Question

Bạn đã bao giờ thấy bất kỳ thông báo lỗi nào chưa?

- SQL Server 2000

Không thể phân bổ bảng phụ trợ cho xem hoặc độ phân giải chức năng.
Đã vượt quá số lượng bảng tối đa trong truy vấn (256).

- SQL Server 2005

Quá nhiều tên bảng trong truy vấn. Số tiền tối đa cho phép là 256.

Nếu có, bạn đã làm gì?

Từ bỏ? Thuyết phục khách hàng để đơn giản hóa nhu cầu của họ? Không chuẩn hóa cơ sở dữ liệu?

---

@ (tất cả mọi người muốn tôi để gửi truy vấn):

1. Tôi không chắc chắn nếu tôi có thể dán 70 kilobyte mã trong cửa sổ câu trả lời chỉnh sửa.
2. Ngay cả khi tôi có thể điều này sẽ không giúp đỡ vì 70 kilobyte mã này sẽ tham chiếu 20 hoặc 30 lượt xem mà tôi cũng sẽ phải đăng vì nếu không mã sẽ vô nghĩa.

Tôi không muốn nghe như tôi đang khoe khoang ở đây nhưng vấn đề không có trong truy vấn. Các truy vấn là tối ưu (hoặc ít nhất là gần như tối ưu). Tôi đã dành vô số giờ tối ưu hóa chúng, tìm kiếm mọi cột đơn và mọi bảng đơn có thể được gỡ bỏ. Hãy tưởng tượng một báo cáo có 200 hoặc 300 cột phải được lấp đầy bằng một câu lệnh SELECT (vì đó là cách nó được thiết kế cách đây vài năm khi nó vẫn còn là một báo cáo nhỏ).

Answer 1

Đối với SQL Server 2005, tôi khuyên bạn nên sử dụng các biến bảng và một phần xây dựng dữ liệu khi bạn thực hiện.

Để thực hiện việc này, hãy tạo biến bảng đại diện cho tập kết quả cuối cùng của bạn mà bạn muốn gửi cho người dùng.

Sau đó, tìm bảng chính của bạn (nói bảng đơn đặt hàng trong ví dụ ở trên) và kéo dữ liệu đó, cộng thêm một chút dữ liệu bổ sung chỉ nói một tham gia (tên khách hàng, tên sản phẩm). Bạn có thể thực hiện lệnh SELECT INTO để đặt giá trị này vào biến bảng của bạn.

Từ đó, lặp qua bảng và cho mỗi hàng, thực hiện một loạt truy vấn SELECT nhỏ để truy xuất tất cả dữ liệu bổ sung mà bạn cần cho tập kết quả của mình. Chèn chúng vào mỗi cột khi bạn đi.

Sau khi hoàn tất, bạn có thể thực hiện một SELECT đơn giản * từ biến bảng của bạn và trả về kết quả này được đặt cho người dùng.

Tôi không có bất kỳ số cứng nào cho điều này, nhưng đã có ba trường hợp khác nhau mà tôi đã làm việc cho đến nay khi thực hiện các truy vấn nhỏ hơn này thực sự hoạt động nhanh hơn thực hiện một truy vấn chọn lớn với một loạt các kết nối.

Answer 2

Tôi chưa bao giờ bắt gặp loại tình huống này và thành thật mà nói, ý tưởng tham chiếu> 256 bảng trong truy vấn sẽ làm tôi lo sợ.

Câu hỏi đầu tiên của bạn có thể là do "Tại sao lại có quá nhiều" ?, theo sau là "bit thông tin nào tôi KHÔNG cần?" Tôi sẽ lo lắng rằng lượng dữ liệu được trả về từ một truy vấn như vậy sẽ bắt đầu tác động đến hiệu suất của ứng dụng khá nghiêm trọng.

Answer 3

Tôi muốn xem truy vấn đó, nhưng tôi cho rằng đó là một số vấn đề với một số loại trình vòng lặp, và trong khi tôi không thể nghĩ ra bất kỳ tình huống nào có thể, tôi đặt cược từ một trường hợp xấu/case/cursor hoặc một tấn quan điểm kém được thực hiện.

Answer 4

@chopeen Bạn có thể thay đổi cách bạn tính toán các thống kê này, thay vào đó, hãy giữ một bảng riêng biệt cho tất cả thống kê mỗi sản phẩm .. khi đặt hàng, lặp qua các sản phẩm và cập nhật các bản ghi thích hợp trong số liệu thống kê bàn. Điều này sẽ thay đổi rất nhiều tải tính toán cho trang thanh toán thay vì chạy mọi thứ trong một truy vấn lớn khi chạy báo cáo. Tất nhiên có một số số liệu thống kê sẽ không hoạt động theo cách này, ví dụ: theo dõi mua hàng tiếp theo của khách hàng sau khi mua một sản phẩm cụ thể.

Answer 5

bài viết truy vấn: D

Ngoài ra tôi cảm thấy như một trong những vấn đề có thể có thể có một tấn (đọc 200) của bảng tên/giá trị mà có thể ngưng tụ thành một bảng tra cứu duy nhất.

Answer 6

Điều này sẽ xảy ra mọi lúc khi viết Báo cáo dịch vụ báo cáo cho các cài đặt Dynamics CRM chạy trên SQL Server 2000. CRM có lược đồ dữ liệu chuẩn hóa độc đáo dẫn đến nhiều lần tham gia. Có thực sự là một hotfix xung quanh đó sẽ tăng giới hạn từ 256 đến một con số khổng lồ 260: http://support.microsoft.com/kb/818406 (chúng tôi luôn luôn nghĩ rằng đây là một trò đùa tuyệt vời trên một phần của đội ngũ SQL Server). Một giải pháp, theo Dillie-O, là xác định các "sub-join" thích hợp (tốt nhất là các phần tử được sử dụng nhiều lần) và đưa chúng vào các biến temp-table mà bạn sử dụng trong các phép nối chính của bạn. Đó là một PIA lớn và thường giết chết hiệu suất. Tôi xin lỗi vì bạn.

@Kevin, yêu thích tee đó - nói tất cả :-).

Answer 7

Tôi đã có cùng một vấn đề này ... hộp phát triển của tôi chạy SQL Server 2008 (chế độ xem đã hoạt động tốt) nhưng về sản xuất (với SQL Server 2005) chế độ xem không có. Tôi đã kết thúc việc tạo các khung nhìn để tránh giới hạn này, bằng cách sử dụng các khung nhìn mới như một phần của truy vấn trong khung nhìn đã ném ra lỗi.

Kind ngớ ngẩn xem xét việc thực hiện logic là như nhau ...

Answer 8

Đã cùng một vấn đề trong SQL Server 2005 (làm việc trong năm 2008) khi tôi muốn tạo ra một cái nhìn. Tôi đã giải quyết vấn đề bằng cách tạo một thủ tục được lưu trữ thay vì một khung nhìn.