Các lựa chọn thay thế tốt cho SQL (ngôn ngữ) là gì? [đóng cửa]

Tôi thỉnh thoảng nghe những điều về cách SQL tệ và nó không phải là một ngôn ngữ tốt, nhưng tôi chưa bao giờ thực sự nghe nhiều về các lựa chọn thay thế cho nó. Vì vậy, các ngôn ngữ tốt khác có phục vụ cùng một mục đích (truy cập cơ sở dữ liệu) và điều gì làm cho chúng tốt hơn SQL? Có bất kỳ cơ sở dữ liệu tốt nào sử dụng ngôn ngữ thay thế này không?

CHỈNH SỬA: Tôi quen thuộc với SQL và sử dụng nó mọi lúc. Tôi không có vấn đề với nó, tôi chỉ quan tâm đến bất kỳ lựa chọn thay thế nào có thể tồn tại và tại sao mọi người thích chúng hơn.

Tôi cũng không tìm kiếm các loại cơ sở dữ liệu thay thế (phong trào NoSQL), chỉ là các cách truy cập cơ sở dữ liệu khác nhau.

Tôi chắc chắn đồng ý rằng cú pháp của SQL rất khó làm việc, cả từ quan điểm tự động tạo ra nó và từ quan điểm phân tích cú pháp, và đó không phải là phong cách ngôn ngữ mà chúng ta sẽ viết ngày hôm nay nếu chúng ta thiết kế SQL cho những yêu cầu mà chúng ta đặt ra vào ngày hôm nay. Tôi không nghĩ rằng chúng ta sẽ tìm thấy nhiều từ khóa đa dạng như vậy nếu chúng ta thiết kế ngôn ngữ ngày nay, tôi nghi ngờ cú pháp nối sẽ khác, các hàm như GROUP_CONCATsẽ có cú pháp thông thường hơn thay vì dán nhiều từ khóa vào giữa dấu ngoặc đơn để kiểm soát hành vi của nó ... tạo danh sách giặt là của riêng bạn về các mâu thuẫn và dư thừa trong SQL mà bạn muốn / mong đợi sẽ được giải quyết mượt mà nếu chúng tôi thiết kế lại ngôn ngữ ngày hôm nay.

Không có bất kỳ lựa chọn thay thế nào cho SQL để nói với cơ sở dữ liệu quan hệ (tức là SQL như một giao thức), nhưng có nhiều lựa chọn thay thế để viết SQL trong các ứng dụng của bạn. Các lựa chọn thay thế này đã được triển khai dưới dạng giao diện người dùng để làm việc với cơ sở dữ liệu quan hệ. Một số ví dụ về giao diện người dùng bao gồm:

• SchemeQL và CLSQL , có lẽ là linh hoạt nhất, do di sản Lisp của chúng, nhưng chúng cũng trông giống SQL hơn rất nhiều so với các giao diện người dùng khác.
• LINQ (trong .Net)
• ScalaQL và ScalaQuery (trong Scala)
• SqlStatement , ActiveRecord và nhiều thứ khác trong Ruby,
• HaskellDB
• ... danh sách tiếp tục cho nhiều ngôn ngữ khác.

Tôi nghĩ rằng chủ đề cơ bản ngày nay là thay vì thay thế SQL bằng một ngôn ngữ truy vấn mới, thay vào đó chúng tôi đang tạo các giao diện người dùng dành riêng cho ngôn ngữ để ẩn SQL trong các ngôn ngữ lập trình thông thường hàng ngày của chúng tôi và coi SQL là giao thức để nói chuyện với quan hệ cơ sở dữ liệu.

Hãy xem danh sách này.

Ngôn ngữ truy vấn Hibernate có lẽ là ngôn ngữ phổ biến nhất. Ưu điểm của Hibernate là các đối tượng ánh xạ rất dễ dàng (gần như tự động) tới cơ sở dữ liệu quan hệ và nhà phát triển không phải mất nhiều thời gian để thiết kế cơ sở dữ liệu. Kiểm tra trang web Hibernate để biết thêm thông tin. Tôi chắc rằng những người khác sẽ thích thú với các ngôn ngữ truy vấn thú vị khác ...

Tất nhiên, có rất nhiều thứ NoSQL ở đó, nhưng bạn đặc biệt đề cập rằng bạn không quan tâm đến những thứ đó.

"Tôi thỉnh thoảng nghe những điều về cách SQL tệ và nó không phải là một ngôn ngữ tốt"

SQL đã hơn ba mươi tuổi. Những hiểu biết sâu sắc về "những tính năng nào khiến một thứ gì đó trở thành một ngôn ngữ 'tốt' và những tính năng nào khiến nó trở thành một ngôn ngữ 'xấu'" đã phát triển nhanh hơn chính SQL.

Ngoài ra, SQL không phải là một ngôn ngữ tuân theo các tiêu chuẩn hiện tại về "những gì nó cần để trở thành quan hệ", vì vậy, SQL chỉ không phải là một ngôn ngữ quan hệ để khởi động.

"nhưng tôi chưa bao giờ thực sự nghe nhiều về các lựa chọn thay thế cho nó."

Tôi mời bạn suy ngẫm về khả năng bạn đang cố gắng chỉ nghe ở những chỗ sai (nghĩa là dành riêng cho ngành DBMS thương mại).

"Vì vậy, các ngôn ngữ tốt khác có phục vụ cùng một mục đích (truy cập cơ sở dữ liệu) và điều gì làm cho chúng tốt hơn SQL?"

Date & Darwen mô tả các tính năng mà một ngôn ngữ thao tác dữ liệu hiện đại phải tuân theo trong "Tuyên ngôn thứ ba", phiên bản gần đây nhất được trình bày trong cuốn sách "Cơ sở dữ liệu, các loại & mô hình quan hệ" của họ.

"Có bất kỳ cơ sở dữ liệu tốt nào sử dụng ngôn ngữ thay thế này không?"

Nếu "tốt", bạn có nghĩa là "sức mạnh công nghiệp", thì không. Thứ gần nhất có sẵn có lẽ sẽ là Dataphor.

Dự án Rel cung cấp một triển khai cho ngôn ngữ Hướng dẫn D được định nghĩa trong "Cơ sở dữ liệu, các loại & mô hình quan hệ", nhưng mục tiêu chính hiện tại của Rel là mang tính giáo dục.

Dự án SIRA_PRISE của tôi cung cấp một triển khai để quản lý dữ liệu "thực sự quan hệ", nhưng tôi cũng ngại gắn nhãn nó là "triển khai một ngôn ngữ".

Và tất nhiên, bạn cũng có thể xem xét một số nội dung không quan hệ, như một số người đã đề xuất, nhưng cá nhân tôi loại bỏ quản lý dữ liệu không quan hệ vì nhiều thập kỷ thoái trào công nghệ. Không đáng để xem xét, đó là.

Nhân tiện, một hệ thống phần mềm được sử dụng để quản lý cơ sở dữ liệu không phải là "cơ sở dữ liệu", mà là "Hệ thống quản lý DataBase", viết tắt là "DBMS". Giống như một bức ảnh không giống với một chiếc máy ảnh, và nếu bạn đang thảo luận về máy ảnh, và bạn muốn tránh nhầm lẫn, thì bạn nên sử dụng từ thích hợp "máy ảnh" thay vì "ảnh".

Có lẽ bạn đang nghĩ đến những lời chỉ trích mà C. Date và những người bạn của anh ấy đã thốt ra chống lại cơ sở dữ liệu quan hệ và SQL hiện có; họ nói rằng hệ thống và ngôn ngữ không phải là quan hệ 100% và nên như vậy. Tôi không thực sự thấy bất kỳ vấn đề thực sự nào ở đây; Theo như tôi thấy, bạn có thể có một hệ thống quan hệ 100%, nếu bạn muốn, chỉ bằng cách tuân thủ cách bạn sử dụng SQL.

Những gì cá nhân tôi tiếp tục gặp phải là thiếu sức mạnh biểu đạt SQL kế thừa từ cơ sở lý thuyết của nó, đại số quan hệ. Một vấn đề là thiếu hỗ trợ cho việc sử dụng thứ tự tên miền mà bạn gặp phải khi làm việc với dữ liệu được đánh dấu bằng ngày tháng, dấu thời gian, vân vân. Tôi đã từng cố gắng thực hiện một ứng dụng báo cáo hoàn toàn bằng SQL thuần túy trên cơ sở dữ liệu đầy dấu thời gian và nó không khả thi. Một vấn đề khác là thiếu hỗ trợ cho việc duyệt đường dẫn: hầu hết dữ liệu của tôi trông giống như các đồ thị có hướng mà tôi cần để duyệt các đường dẫn và SQL không thể làm điều đó. (Nó thiếu "sự đóng cửa bắc cầu". SQL-1999 có thể làm điều đó với "truy vấn con đệ quy" nhưng tôi chưa thấy chúng trong thực tế sử dụng. Cũng có nhiều cách hack khác nhau để làm cho SQL đối phó nhưng chúng rất xấu.) Những vấn đề này là nhân tiện cũng được thảo luận bởi một số bài viết của Date.

Gần đây, tôi đã được chỉ ra .QL dường như giải quyết tốt vấn đề đóng bắc cầu , nhưng tôi không biết liệu nó có thể giải quyết vấn đề với các miền có thứ tự hay không.

Câu trả lời trực tiếp: Tôi không nghĩ có bất kỳ đối thủ nặng ký nào ngoài kia. DBase và những kẻ bắt chước nó (Foxpro, Codebase, v.v.) là đối thủ trong một thời gian, nhưng tôi nghĩ về cơ bản họ đã thua trong cuộc chiến ngôn ngữ truy vấn cơ sở dữ liệu. Đã có nhiều sản phẩm cơ sở dữ liệu khác có ngôn ngữ truy vấn riêng của chúng, như Tiến trình và Nghịch lý và một số sản phẩm khác mà tôi đã sử dụng mà tôi không nhớ tên và chắc chắn nhiều sản phẩm khác mà tôi chưa bao giờ nghe đến. Nhưng tôi không nghĩ rằng bất kỳ đối thủ nào khác thậm chí đã gần đạt được thị phần không nhỏ trên thị trường.

Như một bằng chứng đơn giản rằng có sự khác biệt giữa định dạng cơ sở dữ liệu và ngôn ngữ truy vấn, phiên bản DBase cuối cùng mà tôi đã sử dụng - cách đây nhiều năm - đã cung cấp cả ngôn ngữ truy vấn DBase "truyền thống" và SQL, cả hai đều có thể được sử dụng để truy cập cùng một dữ liệu.

Luyên thuyên bên lề: Tôi sẽ không nói rằng SQL tệ, nhưng nó có nhiều sai sót. Với lợi ích của nhiều năm kinh nghiệm và nhận thức sâu sắc mà chúng tôi hiện có, tôi chắc chắn rằng người ta có thể thiết kế một ngôn ngữ truy vấn tốt hơn. Nhưng tạo ra một ngôn ngữ truy vấn tốt hơn và thuyết phục mọi người sử dụng nó là hai việc rất khác nhau. Liệu nó có đủ tốt hơn để thuyết phục mọi người rằng nó đáng để học hỏi. Mọi người đã đầu tư nhiều năm cuộc đời của họ để học cách sử dụng SQL một cách hiệu quả. Ngay cả khi ngôn ngữ mới của bạn dễ sử dụng hơn, chắc chắn sẽ có một lộ trình học tập. Và bạn sẽ di chuyển hệ thống hiện tại của mình từ SQL sang ngôn ngữ mới như thế nào? Vv. Tất nhiên, nó có thể được thực hiện, giống như C ++, C # và Java đã lật đổ phần lớn COBOL và FORTRAN. Nhưng cần có sự kết hợp giữa ưu thế kỹ thuật và tiếp thị tốt để phát huy hiệu quả.

Tuy nhiên, tôi nhận được một tiếng cười khúc khích với những người vội vàng bảo vệ SQL bất cứ lúc nào ai đó chỉ trích nó, những người nhấn mạnh rằng bất kỳ vấn đề nào bạn gặp phải với SQL phải là do bạn không sử dụng nó chứ không phải lỗi của SQL, mà bạn không được mắc phải đạt đến mức độ cao hơn của sự vật cần thiết để hiểu được sự hoàn hảo của nó, v.v. Bình tĩnh, hít thở sâu: Chúng tôi đang xúc phạm một ngôn ngữ máy tính, không phải mẹ bạn.

Hãy xem LINQ to SQL ...

Đã thử nó một vài tháng trước và không bao giờ nhìn lại ...

Trở lại những năm 1980, ObjectStore cung cấp quyền truy cập đối tượng trong suốt. Nó giống như một RDBMS cộng với ORM, ngoại trừ việc không có tất cả các lớp trừu tượng bị rò rỉ bổ sung đó: nó lưu trữ các đối tượng trực tiếp trong cơ sở dữ liệu.

Vì vậy, thay thế này thực sự là "không có ngôn ngữ nào cả", hoặc có thể là "ngôn ngữ bạn đang sử dụng". Bạn sẽ viết mã C ++ và tạo hoặc duyệt các đối tượng như thể chúng là các đối tượng gốc và cơ sở dữ liệu sẽ xử lý mọi thứ khi cần thiết. Giống như ActiveRecord nhưng nó thực sự hoạt động tốt như tuyên bố tiếp thị ActiveRecord blitzes. :-)

(Tất nhiên, nó không có cơ hội tiếp thị của Oracle, và nó không có MySQL bằng không, vì vậy mọi người đều bỏ qua nó. Và bây giờ chúng tôi cố gắng tái tạo điều đó với RDBMS và ORM, và một số người cố gắng tranh luận rằng bảng thực sự có ý nghĩa với việc lưu trữ các đối tượng và việc viết tệp XML khổng lồ để cho máy tính của bạn biết cách ánh xạ các đối tượng vào bảng bằng cách nào đó là một giải pháp hợp lý.)

Phong trào chung những ngày này là NoSQL; nói chung những công nghệ này là:

• "Bảng băm" phân tán lưu trữ dữ liệu dưới dạng các cặp khóa / giá trị
• Cơ sở dữ liệu hướng tài liệu

Cá nhân tôi nghĩ rằng không có gì sai với SQL miễn là nó phù hợp với nhu cầu của bạn. SQL rất dễ hiểu và tuyệt vời để làm việc với dữ liệu có cấu trúc.

Tôi nghĩ bạn có thể quan tâm đến Dataphor , là một môi trường phát triển quan hệ mã nguồn mở với máy chủ cơ sở dữ liệu riêng của nó (nói D) và khả năng lấy giao diện người dùng từ ngôn ngữ truy vấn của nó.

Ngoài ra, có vẻ như Ingres vẫn hỗ trợ QUEL và đó là mã nguồn mở.

SQL hoạt động tốt cho miền mà nó được thiết kế - các bảng dữ liệu có liên quan với nhau. Điều này thường được tìm thấy trong xử lý dữ liệu kinh doanh truyền thống. SQL không hoạt động tốt khi cố gắng duy trì một mạng đối tượng phức tạp.

Nếu nhu cầu của bạn là lưu trữ và xử lý dữ liệu tương đối truyền thống, hãy sử dụng một số DBMS dựa trên SQL.

Đáp lại chỉnh sửa của bạn:

Nếu bạn đang tìm kiếm các giải pháp thay thế cho SQL DML để truy xuất dữ liệu từ các kho dữ liệu quan hệ, thì tôi chưa bao giờ nghe nói về bất kỳ sự thay thế nghiêm túc nào cho SQL.

Tôi nghĩ rằng những rắc rối mà SQL nhận được không chống lại ngôn ngữ này quá nhiều so với các nguyên tắc lưu trữ dữ liệu cơ bản mà ngôn ngữ này dựa trên đó. Mọi người thường nhầm lẫn ngôn ngữ SQL với mô hình dữ liệu quan hệ mà các RDBMS được xây dựng trên đó.

Cơ sở dữ liệu quan hệ không phải là loại cơ sở dữ liệu duy nhất xung quanh. Tôi nên nói một từ về Cơ sở dữ liệu đối tượng vì tôi đã không thấy nó trong các phản hồi từ những người khác. Tôi đã có một số kinh nghiệm với khuôn khổ Zope python sử dụng ZODB cho tính bền bỉ của đối tượng thay vì RDBMS (về lý thuyết, có thể thay thế ZODB bằng một cơ sở dữ liệu khác trong zope nhưng lần cuối cùng tôi kiểm tra, tôi đã không thành công để nó hoạt động, vì vậy có thể không tích cực về điều đó).

Tư duy ZODB thực sự khác biệt, giống như lập trình đối tượng sẽ diễn ra liên tục.

ORM có thể được xem như một loại ngôn ngữ

Theo một cách nào đó, tôi tin rằng mô hình Cơ sở dữ liệu-đối tượng là mô hình ORM: truy cập dữ liệu liên tục thông qua mô hình đối tượng thông thường của bạn. Đó là một loại ngôn ngữ và nó đang giành được một số thị phần, nhưng hiện tại chúng ta không coi nó là một ngôn ngữ mà là một lớp trừu tượng. Tuy nhiên, tôi tin rằng sẽ hiệu quả hơn nhiều nếu sử dụng ORM trên Cơ sở dữ liệu đối tượng hơn là SQL (nói cách khác là hiệu suất của ORM mà tôi đã tình cờ sử dụng bằng cách sử dụng một số cơ sở dữ liệu SQL làm lớp cơ sở bị hút).

Có nhiều cách triển khai SQL (SQL Server, mysql, Oracle, v.v.), nhưng không có ngôn ngữ nào khác phục vụ cùng mục đích theo nghĩa là ngôn ngữ có mục đích chung được thiết kế để lưu trữ và truy xuất dữ liệu quan hệ .

Có những cơ sở dữ liệu đối tượng như db4o và có những cơ sở dữ liệu noSQL tương tự được gọi là cơ sở dữ liệu chỉ về bất kỳ cơ chế lưu trữ dữ liệu nào không dựa trên SQL, nhưng phổ biến nhất là các sản phẩm nguồn mở như Cassandra dựa trên khái niệm Bigtable của Google .

Ngoài ra còn có một số sản phẩm cơ sở dữ liệu có mục đích đặc biệt như CDF, nhưng bạn có thể không cần phải lo lắng về những điều đó - nếu bạn cần, bạn sẽ biết.

Không có cái nào tương đương với SQL.

Điều đó không có nghĩa là chúng "tốt hơn" hay "tệ hơn" - chúng không giống nhau. Dennis Forbes đã viết một bài đăng tuyệt vời gần đây đã phá vỡ một số tuyên bố kỳ lạ chống lại SQL. Anh ấy khẳng định (và tôi đồng ý) rằng những phàn nàn này phần lớn bắt nguồn từ những người và cửa hàng, những người đã chọn sai công cụ cho công việc ngay từ đầu hoặc không sử dụng SQL DBMS của họ đúng cách (tôi thậm chí không còn ngạc nhiên nữa khi tôi xem một cơ sở dữ liệu SQL khác trong đó mọi cột là một varchar(50)và không có một chỉ mục hoặc khóa nào, ở bất kỳ đâu).

Nếu bạn đang triển khai một trang web mạng xã hội khác và không quá quan tâm đến các nguyên tắc của ACID , bằng mọi cách, hãy bắt đầu xem xét các sản phẩm như db4o. Nếu bạn đang phát triển một hệ thống kinh doanh quan trọng, tuy nhiên, tôi đánh giá cao rất khuyên bạn nên suy nghĩ cẩn thận trước khi tham gia "SQL sucks" điệp khúc. Trước tiên, hãy nghiên cứu, tìm ra những tính năng mà các sản phẩm khác nhau có thể và không thể hỗ trợ.

Chỉnh sửa - Tôi đang bận viết câu trả lời của mình và không nhận được cập nhật câu hỏi trong vài phút. Phải nói rằng, SQL về cơ bản không thể tách rời khỏi chính DBMS. Nếu bạn chạy một sản phẩm cơ sở dữ liệu SQL, thì bạn truy cập nó bằng SQL, dấu chấm.

Có lẽ bạn đang tìm kiếm sự trừu tượng về cú pháp; Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic và một loạt các công cụ ORM khác đều cung cấp cú pháp giống SQL của riêng chúng mà không hoàn toàn là SQL. Tất cả những "biên dịch xuống" SQL. Nếu bạn chạy SQL Server, thì bạn cũng có thể viết Hàm / Thủ tục / Kích hoạt CLR, cho phép bạn viết mã bằng bất kỳ ngôn ngữ .NET nào sẽ chạy bên trong cơ sở dữ liệu; tuy nhiên, đây không thực sự thay thế cho SQL, mà nó còn là một phần mở rộng hơn.

Tôi không biết bất kỳ "ngôn ngữ" đầy đủ nào mà bạn có thể xếp lớp trên cơ sở dữ liệu SQL; thiếu việc chuyển sang một sản phẩm cơ sở dữ liệu khác, cuối cùng bạn sẽ thấy SQL trên đường ống.

SQL là thực tế.

Các khung công tác cố gắng bảo vệ các nhà phát triển khỏi nó cuối cùng đã tạo ra ngôn ngữ cụ thể của riêng họ (Hibernate HQL được nghĩ đến).

SQL giải quyết một vấn đề khá tốt. Nó không khó học hơn một ngôn ngữ lập trình cấp cao. Nếu bạn đã biết một ngôn ngữ chức năng thì việc nắm bắt SQL thật dễ dàng.

Xem xét các nhà cung cấp cơ sở dữ liệu hàng đầu cung cấp cơ sở dữ liệu hiện đại (Oracle và SQL Server) hỗ trợ SQL và đã đầu tư nhiều năm vào các công cụ tối ưu hóa, v.v. và tất cả các giao dịch phần mềm quản lý thay đổi và phần mềm lập mô hình dữ liệu hàng đầu trong SQL, tôi muốn nói đó là đặt cược an toàn nhất.

Ngoài ra, có nhiều thứ đối với cơ sở dữ liệu hơn là chỉ truy vấn. Có khả năng mở rộng, sao lưu và phục hồi, khai thác dữ liệu. Các nhà cung cấp lớn hỗ trợ rất nhiều thứ mà ngay cả các engine "cache" mới thậm chí còn không tính đến.

Các vấn đề với SQL đã thúc đẩy tôi tạo ra một ngôn ngữ truy vấn nháp có tên là SMEQL tại wiki của Kho lưu trữ Mẫu Portland . Bình luận Chào mừng bạn. Nó vay mượn ý tưởng từ lập trình chức năng và ngôn ngữ Hệ thống kinh doanh 12 thử nghiệm của IBM. (Ban đầu tôi gọi nó là TQL, nhưng sau đó thấy tên đó đã được sử dụng.)

Trong thế giới .NET, mặc dù nó vẫn mang cảm giác SQL-esque đối với nó, nhưng LINQ-to-SQL sẽ cho phép bạn kết hợp tốt giữa SQL và xử lý trong bộ nhớ .NET dữ liệu của bạn. Nó cũng đơn giản hóa rất nhiều hệ thống ống dẫn dữ liệu cấp thấp hơn mà không ai thực sự muốn làm.

Nếu bạn muốn xem một loại cơ sở dữ liệu có tư duy hoàn toàn khác, hãy xem CouchDB . "Tốt hơn" rõ ràng là một yêu cầu tương đối và loại cơ sở dữ liệu phi quan hệ này là "Tốt hơn" nhưng chỉ trong một số trường hợp nhất định.

SQL là ngôn ngữ rất mạnh mẽ, và các hệ quản trị cơ sở dữ liệu quan hệ đã và vẫn đang là một thành công lớn. Nhưng có một lớp ứng dụng yêu cầu khả năng mở rộng và tính sẵn sàng rất cao, nhưng không nhất thiết phải có mức độ nhất quán dữ liệu cao (cuối cùng tính nhất quán mới là điều quan trọng). Nhiều hệ thống có hiệu suất và khả năng mở rộng tốt hơn RDBMS bằng cách giảm nhu cầu giao dịch tuân thủ ACID đầy đủ. Chúng được đặt tên là "NoSQL", nhưng như những người khác chỉ ra, đây là một cách viết sai: có lẽ chúng nên được gọi là cơ sở dữ liệu NoACID.

Michael Stonebraker trình bày vấn đề này trong Cuộc thảo luận "NoSQL" Không liên quan gì đến SQL .