Mở rộng SQL bắt

Theo Immerman , lớp phức tạp liên quan đến các truy vấn SQL chính xác là lớp truy vấn an toàn trong (truy vấn bậc một cộng với toán tử đếm): SQL nắm bắt các truy vấn an toàn. (Nói cách khác, tất cả các truy vấn SQL có độ phức tạp trong và tất cả các vấn đề trong có thể được biểu thị dưới dạng truy vấn SQL.)$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$

Dựa trên kết quả này, từ quan điểm lý thuyết, có nhiều vấn đề thú vị có thể được giải quyết hiệu quả nhưng không thể diễn tả được trong SQL. Do đó, một phần mở rộng của SQL vẫn còn hiệu quả có vẻ thú vị. Vì vậy, đây là câu hỏi của tôi:

Có phần mở rộng của SQL (được triển khai và sử dụng trong ngành ) để nắm bắt$\mathsf{P}$ (nghĩa là có thể diễn tả tất cả các truy vấn tính toán theo thời gian đa thức và không có truy vấn nào khác) không?

Tôi muốn một ngôn ngữ truy vấn cơ sở dữ liệu đáp ứng cả ba điều kiện. Thật dễ dàng để xác định một phần mở rộng sẽ mở rộng SQL và sẽ nắm bắt . Nhưng câu hỏi của tôi là nếu một ngôn ngữ như vậy có ý nghĩa từ quan điểm thực tế, vì vậy tôi muốn một ngôn ngữ đang được sử dụng trong thực tế. Nếu đây không phải là trường hợp và không có ngôn ngữ như vậy, thì tôi muốn biết liệu có lý do nào khiến ngôn ngữ đó không thú vị theo quan điểm thực tế không? Ví dụ, các truy vấn tăng trong thực tế thường đủ đơn giản để không cần một ngôn ngữ như vậy?$\mathsf{P}$

Đối với câu hỏi chính của bạn, tôi đề nghị khảo sát ngắn này của Martin Grohe.

Các truy vấn cần thiết trong thực tế thường đủ đơn giản để không cần một ngôn ngữ mạnh hơn?

Tôi muốn nói rằng điều này chiếm phần lớn thời gian, với số lượng mở rộng hợp lý được thêm vào các ngôn ngữ truy vấn phổ biến (đóng cửa bắc cầu, toán tử số học, đếm, v.v.). Điều này xuất phát từ quan điểm của một người nào đó đã thực hiện một số công việc như một nhà phát triển tự do của các trang web tương đối đơn giản và các ứng dụng khác, vì vậy tôi không chắc chắn về việc sử dụng SQL thực sự trong các ngành công nghiệp lớn hơn / cơ sở dữ liệu lớn hơn.

Trong những trường hợp hiếm hoi có thể cần một ngôn ngữ mạnh hơn, tôi đoán là các nhà phát triển phần mềm xử lý chúng bằng cách sử dụng ngôn ngữ mà họ viết ứng dụng, chứ không phải các truy vấn (như C ++ hoặc java).

Đầu tiên, sức mạnh biểu cảm của SQL ít rõ ràng hơn dường như. Các tính năng tổng hợp, nhóm và số học của SQL hóa ra lại có các hiệu ứng khá tinh tế. Một tiên nghiệm, có vẻ khả thi khi bằng cách mã hóa các toán tử đại số sử dụng các tính năng này, người ta thực sự có thể biểu thị khả năng tiếp cận trong SQL. Hóa ra đây không phải là trường hợp thực sự của SQL-92 , là "cục bộ".

• Leonid Libkin. Sức mạnh biểu cảm của SQL , TCS 296 (3), 379 Chân404. doi: 10.1016 / S0304-3975 (02) 00736-3 ( in sẵn )

Điều này có nghĩa là phần mở rộng được yêu cầu cho SQL-92 để thu thập PTIME và một phần mở rộng cho phép ngôn ngữ kết quả là "không cục bộ".

Tuy nhiên, cho phép ra lệnh cho các cấu trúc và với thực tế giới hạn số học, chứng minh rằng SQL-92 không thể diễn tả reachability có ngụ ý rằng đồng phục và do đó có thể sẽ là khá khó khăn. (Có thể lập luận rằng một trật tự tuyến tính tự nhiên luôn tồn tại trên các kiểu dữ liệu trong SQL-92 và do đó người ta có thể cho rằng các cấu trúc cơ bản được sắp xếp theo thứ tự.)$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

Sau đó, cảnh quan thay đổi một lần nữa, vì SQL: 1999 (SQL3) bao gồm đệ quy. Vì vậy, SQL: 1999 dường như ít nhất là biểu cảm như logic điểm cố định với việc đếm (mặc dù tôi nghĩ các chi tiết có thể lại khá phức tạp, bao gồm cả vấn đề về trật tự). Liệu các cấu trúc mới có làm cho logic biểu cảm hơn mức cần thiết để nắm bắt PTIME hay không, tôi không biết, và một số nghiên cứu sẽ được yêu cầu để thiết lập điều này. Trong khi đó, các sửa đổi tiếp theo đã được thực hiện vào năm 2003 , 2006 , 2008 và 2011(là tài liệu ISO, chỉ có bản nháp là có sẵn miễn phí). Các bản sửa đổi này đã thêm một loạt các tính năng mới, bao gồm cho phép XQuery là "một phần" của các truy vấn SQL. Tôi đoán là "SQL" bây giờ biểu cảm hơn mức cần thiết để nắm bắt PTIME, nhưng mã hóa được yêu cầu để làm như vậy có thể yêu cầu các truy vấn lớn và khá tự nhiên có thể không được hỗ trợ trong các hệ thống thực.

Vì vậy, tôi nghĩ rằng có bằng chứng cho thấy không có phần mở rộng công nghiệp nào của SQL nắm bắt chính xác PTIME , trả lời câu hỏi của bạn một cách mờ nhạt. Nói tóm lại, các phần mở rộng công nghiệp khá mạnh mẽ và có thể đã vượt quá PTIME. Nếu đúng là SQL: 1999 đã đủ mạnh để nắm bắt ít nhất PTIME, thì cũng không rõ "SQL" thực sự có nghĩa gì trong câu hỏi của bạn, vì người ta sẽ phải định nghĩa "SQL" để có nghĩa là một phiên bản có trước SQL: 1999.

$\text{P} \ne \text{NP}$

• Martin Grohe, Cuộc tìm kiếm logic nắm bắt PTIME , LICS 2008, 267 Tiết271. doi: 10.1109 / LICS.2008.11 ( in sẵn )

$P$$P$$P$$P$$P$

$P = NP$$P = NP$$P$$P$$NPC$

$P \ne NP$

$P = NP$

Mặc dù nó có thể không tồn tại cho mục đích thực sự, nhưng nó chắc chắn tồn tại và có thể xây dựng và thực hiện được. Bạn có thể xác định ngôn ngữ đó với thứ gì đó có khả năng mô phỏng máy Turing theo số bước đơn nhất định. IE, có khả năng giải quyết vấn đề P- Complete. Tuy nhiên, nếu bạn xây dựng một thứ như vậy, nó gần như hoàn thành Turing ngoại trừ hạn chế "được đưa ra một số bước duy nhất", mà trong một ngôn ngữ giống như SQL sẽ là một cách rất lạ để giới hạn nó chỉ trong các truy vấn an toàn. Bạn có thể làm điều này nếu các bước là bản ghi của một số bảng, nhưng điều này vẫn không có vẻ gì có giá trị cho các mục đích thực tế.