Tại sao không yêu SQL? [đóng cửa]

Gần đây tôi đã nghe nói rất nhiều về SQL là một ngôn ngữ khủng khiếp, và có vẻ như mọi khuôn khổ dưới ánh mặt trời đều được đóng gói sẵn với một lớp trừu tượng cơ sở dữ liệu.

Theo kinh nghiệm của tôi, SQL thường là cách dễ dàng hơn, linh hoạt hơn và thân thiện hơn với lập trình viên để quản lý đầu vào và đầu ra dữ liệu. Mọi lớp trừu tượng mà tôi đã sử dụng dường như là một cách tiếp cận hạn chế rõ rệt mà không có lợi ích thực sự.

Điều gì làm cho SQL trở nên khủng khiếp và tại sao các lớp trừu tượng cơ sở dữ liệu lại có giá trị?

Điều này một phần là chủ quan. Vì vậy, đây là ý kiến ​​của tôi:

SQL có kiểu ngôn ngữ giả tự nhiên . Các nhà phát minh tin rằng họ có thể tạo ra một ngôn ngữ giống như tiếng Anh và các truy vấn cơ sở dữ liệu sẽ rất đơn giản. Một sai lầm khủng khiếp. SQL rất khó hiểu ngoại trừ những trường hợp nhỏ nhặt.

SQL là khai báo. Bạn không thể nói cho cơ sở dữ liệu biết nó sẽ làm công việc như thế nào , chỉ là kết quả bạn muốn. Điều này sẽ hoàn hảo và rất mạnh mẽ - nếu bạn không phải quan tâm đến hiệu suất. Vì vậy, bạn kết thúc bằng việc viết SQL - đọc các kế hoạch thực thi - diễn đạt lại SQL cố gắng tác động đến kế hoạch thực thi, và bạn tự hỏi tại sao bạn không thể tự viết kế hoạch thực thi .

Một vấn đề khác của ngôn ngữ khai báo là một số vấn đề dễ giải quyết hơn theo cách mệnh lệnh. Vì vậy, bạn có thể viết nó bằng một ngôn ngữ khác (bạn sẽ cần SQL tiêu chuẩn và có thể là một lớp truy cập dữ liệu) hoặc bằng cách sử dụng các phần mở rộng ngôn ngữ cụ thể của nhà cung cấp, chẳng hạn như bằng cách viết các thủ tục được lưu trữ và tương tự. Làm như vậy, bạn có thể sẽ thấy rằng bạn đang sử dụng một trong những ngôn ngữ tồi tệ nhất mà bạn từng thấy - bởi vì nó chưa bao giờ được thiết kế để sử dụng như một ngôn ngữ mệnh lệnh.

SQL rất cũ . SQL đã được chuẩn hóa, nhưng quá muộn, nhiều nhà cung cấp đã phát triển phần mở rộng ngôn ngữ của họ. Vì vậy, SQL kết thúc bằng hàng chục phương ngữ. Đó là lý do tại sao các ứng dụng không có tính di động và một lý do để có một lớp trừu tượng DB.

Nhưng đó là sự thật - không có lựa chọn thay thế khả thi nào. Vì vậy, tất cả chúng ta sẽ sử dụng SQL trong vài năm tới.

Ngoài tất cả những gì đã nói, một công nghệ không cần phải tệ để làm cho một lớp trừu tượng có giá trị .

Nếu bạn đang thực hiện một tập lệnh hoặc ứng dụng rất đơn giản, bạn có thể đủ khả năng kết hợp các lệnh gọi SQL trong mã của mình ở bất cứ đâu bạn muốn. Tuy nhiên, nếu bạn đang thực hiện một hệ thống phức tạp, thì việc cô lập các lệnh gọi cơ sở dữ liệu trong (các) mô-đun riêng biệt là một phương pháp hay và vì vậy nó đang cô lập mã SQL của bạn. Nó cải thiện khả năng đọc, khả năng bảo trì và khả năng kiểm tra của mã của bạn. Nó cho phép bạn nhanh chóng điều chỉnh hệ thống của mình với những thay đổi trong mô hình cơ sở dữ liệu mà không cần chia nhỏ tất cả những thứ cấp cao, v.v.

SQL là tuyệt vời. Các lớp trừu tượng trên nó làm cho nó thậm chí còn lớn hơn!

Một điểm của các lớp trừu tượng là thực tế là các triển khai SQL có xu hướng ít nhiều không tương thích với nhau vì tiêu chuẩn hơi mơ hồ, và cũng bởi vì hầu hết các nhà cung cấp đã thêm phần bổ sung (không chuẩn) của riêng họ vào đó. Tức là, SQL được viết cho MySQL DB có thể không hoạt động hoàn toàn tương tự với Oracle DB - ngay cả khi nó "nên".

Tuy nhiên, tôi đồng ý rằng SQL tốt hơn hầu hết các lớp trừu tượng ngoài kia. Không phải lỗi của SQL mà nó được sử dụng cho những thứ mà nó không được thiết kế cho.

SQL bị badmouthed từ một số nguồn:

• Các lập trình viên không cảm thấy thoải mái với bất cứ thứ gì ngoại trừ một ngôn ngữ mệnh lệnh.
• Các chuyên gia tư vấn phải xử lý nhiều sản phẩm dựa trên SQL không tương thích hàng ngày
• Các nhà cung cấp cơ sở dữ liệu quan hệ đang cố gắng phá vỡ sự bó buộc của các nhà cung cấp cơ sở dữ liệu quan hệ trên thị trường
• Các chuyên gia cơ sở dữ liệu quan hệ như Chris Date, những người xem việc triển khai SQL hiện tại là không đủ

Nếu bạn gắn bó với một sản phẩm DBMS, thì tôi chắc chắn đồng ý rằng SQL DBs linh hoạt hơn và có chất lượng cao hơn so với đối thủ của chúng, ít nhất là cho đến khi bạn chạm vào rào cản khả năng mở rộng nội tại trong mô hình. Nhưng bạn thực sự đang cố gắng viết Twitter tiếp theo hay bạn chỉ đang cố gắng giữ cho một số dữ liệu kế toán có tổ chức và nhất quán?

Chỉ trích SQL thường là đại diện cho những lời chỉ trích về RDBMS. Điều mà những người chỉ trích RDBMSes dường như không hiểu là chúng giải quyết khá tốt một loại vấn đề máy tính khổng lồ, và chúng ở đây để làm cho cuộc sống của chúng ta dễ dàng hơn chứ không phải khó khăn hơn.

Nếu họ nghiêm túc về việc chỉ trích chính SQL, họ sẽ ủng hộ những nỗ lực như Hướng dẫn D và Dataphor.

Nó không quá khủng khiếp. Đó là một xu hướng đáng tiếc trong ngành này khi loại bỏ công nghệ đáng tin cậy trước đây khi một "mô hình" mới xuất hiện. Vào cuối ngày, các khung công tác này rất có thể sử dụng SQL để giao tiếp với cơ sở dữ liệu, vậy làm sao nó có thể tệ như vậy? Điều đó nói rằng, có một lớp trừu tượng "tiêu chuẩn" có nghĩa là một nhà phát triển có thể tập trung vào mã ứng dụng chứ không phải mã SQL. Nếu không có một lớp tiêu chuẩn như vậy, bạn có thể viết một lớp nhẹ mỗi khi bạn đang phát triển một hệ thống, điều này thật lãng phí công sức.

SQL được thiết kế để quản lý và truy vấn dữ liệu dựa trên SET. Nó thường được sử dụng để làm nhiều hơn và các trường hợp cạnh tranh đôi khi dẫn đến sự thất vọng.

Việc sử dụng SQL trong thực tế có thể bị ảnh hưởng bởi thiết kế cơ sở dữ liệu cơ sở mà SQL có thể không phải là vấn đề, nhưng thiết kế có thể xảy ra - và khi bạn tung mã kế thừa được liên kết với một thiết kế xấu, các thay đổi sẽ ảnh hưởng hơn và tốn kém hơn ( không ai thích quay lại và "sửa chữa" những thứ đang "hoạt động" và đạt được mục tiêu)

Thợ mộc có thể đập đinh bằng búa, cưa gỗ bằng cưa và làm nhẵn ván bằng máy bào. Có thể "cưa" bằng cách sử dụng búa và máy bay, nhưng nó thật bực bội.

Tôi sẽ không nói nó khủng khiếp. Nó không phù hợp cho một số nhiệm vụ. Ví dụ: bạn không thể viết mã thủ tục tốt với SQL. Tôi đã từng bị buộc phải làm việc với thao tác thiết lập với SQL. Tôi đã mất cả cuối tuần để tìm ra điều đó.

SQL được thiết kế cho đại số quan hệ - đó là nơi nó nên được sử dụng.

Gần đây tôi đã nghe nói rất nhiều về SQL là một ngôn ngữ khủng khiếp, và có vẻ như mọi khuôn khổ dưới ánh mặt trời đều được đóng gói sẵn với một lớp trừu tượng cơ sở dữ liệu.

Lưu ý rằng các lớp này chỉ chuyển đổi nội dung của riêng chúng thành SQL. Đối với hầu hết các nhà cung cấp cơ sở dữ liệu SQLlà cách duy nhất để giao tiếp với động cơ.

Theo kinh nghiệm của tôi, SQL thường là cách dễ dàng hơn, linh hoạt hơn và thân thiện hơn với lập trình viên để quản lý đầu vào và đầu ra dữ liệu. Mọi lớp trừu tượng mà tôi đã sử dụng dường như là một cách tiếp cận hạn chế rõ rệt mà không có lợi ích thực sự.

… Lý do mà tôi vừa mô tả ở trên.

Các lớp cơ sở dữ liệu không thêm bất cứ thứ gì, chúng chỉ giới hạn bạn. Chúng làm cho các truy vấn trở nên đơn giản hơn nhưng không bao giờ hiệu quả hơn.

Theo định nghĩa, không có gì trong các lớp cơ sở dữ liệu mà không có trong đó SQL.

Điều gì làm cho nó trở SQLnên khủng khiếp và tại sao các lớp trừu tượng cơ sở dữ liệu lại có giá trị?

SQL là một ngôn ngữ hay, tuy nhiên, để làm việc với nó cần phải có một số thao tác não bộ.

Về lý thuyết, SQLlà khai báo, tức là bạn khai báo những gì bạn muốn nhận được và động cơ cung cấp nó theo cách nhanh nhất có thể.

Trong thực tế, có nhiều cách để hình thành một truy vấn đúng (đó là truy vấn trả về kết quả chính xác).

Các nhà tối ưu hóa có thể xây dựng một lâu đài Lego từ một số thuật toán được xác định trước (vâng, chúng là nhiều), nhưng họ không thể tạo ra các thuật toán mới. Nó vẫn cần một SQLnhà phát triển để hỗ trợ họ.

Tuy nhiên, một số người mong đợi trình tối ưu hóa tạo ra "kế hoạch tốt nhất có thể", không phải "kế hoạch tốt nhất có sẵn cho truy vấn này với việc triển khai SQLcông cụ nhất định".

Và như chúng ta đều biết, khi chương trình máy tính không đáp ứng được mong đợi của mọi người, thì đó là chương trình bị đổ lỗi chứ không phải mong đợi.

Tuy nhiên, trong hầu hết các trường hợp, việc định dạng lại một truy vấn có thể tạo ra một kế hoạch tốt nhất có thể. Tuy nhiên, có những nhiệm vụ khi nó không thể thực hiện được, với những cải tiến mới và ngày càng tăng cho SQLnhững trường hợp này, số lượng ngày càng ít đi.

Tuy nhiên, sẽ rất tuyệt nếu các nhà cung cấp cung cấp một số quyền truy cập cấp thấp vào các chức năng như "lấy phạm vi chỉ mục", "lấy một hàng theo rowid" v.v., chẳng hạn như các Ctrình biên dịch cho phép bạn nhúng hợp ngữ ngay vào ngôn ngữ.

Gần đây tôi đã viết một bài báo về điều này trên blog của tôi:

• Suy nghĩ kép trong SQL

Tôi là một người ủng hộ ORM rất lớn và tôi vẫn tin rằng SQL rất hữu ích, mặc dù chắc chắn có thể làm những điều khủng khiếp với nó (giống như bất kỳ thứ gì khác). .

Tôi xem SQL như một ngôn ngữ siêu hiệu quả không có ưu tiên sử dụng lại mã hoặc khả năng bảo trì / tái cấu trúc.

Vì vậy, xử lý nhanh như chớp là ưu tiên. Và điều đó có thể chấp nhận được. Bạn chỉ cần nhận thức được sự đánh đổi, đối với tôi là đáng kể.

Từ quan điểm thẩm mỹ, với tư cách là một ngôn ngữ, tôi cảm thấy rằng nó thiếu một số thứ vì nó không có các khái niệm OO, v.v. - nó giống như một mã thủ tục rất cũ đối với tôi. Nhưng đó là cách nhanh nhất để làm một số việc nhất định và đó là một thị trường ngách mạnh mẽ!

Tôi muốn nói rằng một lớp trừu tượng cơ sở dữ liệu được bao gồm trong một khuôn khổ là một điều tốt vì nó giải quyết được hai vấn đề rất quan trọng:

1. Nó giữ cho mã khác biệt. Bằng cách đặt SQL vào một lớp khác, lớp này thường rất mỏng và chỉ nên thực hiện những điều cơ bản về truy vấn và chuyển giao kết quả (theo cách chuẩn hóa), bạn giữ cho ứng dụng của mình không bị mớ bòng bong của SQL. Đó cũng là lý do các nhà phát triển web (nên) đặt CSS và Javascript trong các tệp riêng biệt. Nếu bạn có thể tránh nó, đừng trộn lẫn ngôn ngữ của bạn .

2. Nhiều lập trình viên chỉ sử dụng SQL rất tệ. Vì bất cứ lý do gì, một số lượng lớn các nhà phát triển (đặc biệt là các nhà phát triển web) dường như rất rất rất kém trong việc sử dụng SQL hoặc RDBMSes nói chung. Họ coi cơ sở dữ liệu (và SQL bằng phần mở rộng) như một người trung gian nhỏ bé mà họ phải trải qua để truy cập dữ liệu. Điều này dẫn đến cơ sở dữ liệu được suy nghĩ cực kỳ tồi tệ không có chỉ mục, các bảng xếp chồng lên nhau trong cách cư xử không rõ ràng và các truy vấn được viết rất kém. Hoặc tệ hơn, họ cố gắng quá chung chung (Hệ thống chuyên gia, bất kỳ ai?) Và không thể liên hệ dữ liệu một cách hợp lý theo bất kỳ cách nào có ý nghĩa.

Thật không may, đôi khi cách mà ai đó cố gắng giải quyết vấn đề và các công cụ mà họ sử dụng, cho dù do thiếu hiểu biết, bướng bỉnh hay một số đặc điểm khác, lại đối lập trực tiếp với nhau, và chúc may mắn khi cố gắng thuyết phục họ về điều này. Như vậy, ngoài việc là một thực tiễn tốt, tôi coi lớp trừu tượng cơ sở dữ liệu là một loại mạng lưới an toàn, vì nó không chỉ giữ cho SQL khỏi con mắt của nhà phát triển kém, mà còn làm cho mã của họ dễ dàng cấu trúc lại hơn, vì tất cả các truy vấn đều ở một nơi.

SQL là tuyệt vời cho một số loại tác vụ, đặc biệt là thao tác và truy xuất các tập dữ liệu.

Tuy nhiên, SQL thiếu (hoặc chỉ triển khai một phần) một số công cụ quan trọng để quản lý sự thay đổi và phức tạp:

• Tính đóng gói : Các cơ chế đóng gói của SQL là thô. Khi bạn viết mã SQL, bạn phải biết mọi thứ về việc triển khai dữ liệu của mình. Điều này giới hạn số lượng trừu tượng bạn có thể đạt được.

• Tính đa hình : nếu bạn muốn thực hiện cùng một thao tác trên các bảng khác nhau, bạn phải viết mã hai lần. (Người ta có thể giảm thiểu điều này bằng cách sử dụng các khung nhìn theo trí tưởng tượng.)

• Kiểm soát khả năng hiển thị : không có cơ chế SQL tiêu chuẩn nào để ẩn các đoạn mã với nhau hoặc nhóm chúng thành các đơn vị logic, vì vậy mọi bảng, thủ tục, v.v. đều có thể truy cập từ mọi bảng khác, ngay cả khi nó không mong muốn.

• Mô-đun và tạo phiên bản

Cuối cùng, mã hóa thủ công các hoạt động CRUD trong SQL (và viết mã để kết nối nó với phần còn lại của ứng dụng) là lặp đi lặp lại và dễ xảy ra lỗi.

Một lớp trừu tượng hiện đại cung cấp tất cả các tính năng đó và cho phép chúng ta sử dụng SQL ở nơi nó hiệu quả nhất trong khi ẩn các chi tiết triển khai lặp đi lặp lại, gián đoạn. Nó cung cấp các công cụ để giúp khắc phục sự không phù hợp trở kháng quan hệ đối tượng gây phức tạp cho việc truy cập dữ liệu trong phát triển phần mềm hướng đối tượng.

SQL dựa trên Lý thuyết tập hợp, trong khi hầu hết các ngôn ngữ cấp cao ngày nay đều hướng đối tượng. Các lập trình viên đối tượng thường thích suy nghĩ trong các đối tượng và phải thay đổi tinh thần để sử dụng các công cụ dựa trên Set để lưu trữ các đối tượng của họ. Nói chung, sẽ tự nhiên hơn nhiều (đối với lập trình viên OO) chỉ cần cắt mã bằng ngôn ngữ họ chọn và thực hiện một số việc như object.save hoặc object.delete trong mã ứng dụng thay vì phải viết các truy vấn sql và gọi cơ sở dữ liệu để đạt được. cùng một kết quả.

Tất nhiên, đôi khi đối với những thứ phức tạp, SQL dễ sử dụng hơn và hiệu quả hơn, vì vậy sẽ rất tốt nếu bạn có khả năng xử lý cả hai loại công nghệ này.

IMO, vấn đề mà tôi thấy mọi người gặp phải với SQL không liên quan gì đến thiết kế quan hệ cũng như bản thân ngôn ngữ SQL. Nó liên quan đến kỷ luật mô hình hóa lớp dữ liệu, theo nhiều cách, về cơ bản khác với mô hình hóa một lớp nghiệp vụ hoặc giao diện. Các sai lầm trong mô hình hóa ở lớp trình bày thường dễ sửa hơn nhiều so với ở lớp dữ liệu nơi bạn có nhiều ứng dụng sử dụng cơ sở dữ liệu. Những vấn đề này cũng giống như những vấn đề gặp phải khi lập mô hình lớp dịch vụ trong thiết kế SOA, nơi bạn phải tính đến người tiêu dùng hiện tại của dịch vụ của bạn và các hợp đồng đầu vào và đầu ra.

SQL được thiết kế để tương tác với các mô hình cơ sở dữ liệu quan hệ. Có những mô hình dữ liệu khác đã tồn tại trong một thời gian, nhưng kỷ luật về thiết kế lớp dữ liệu đúng cách vẫn tồn tại bất kể mô hình lý thuyết được sử dụng là gì và do đó, những khó khăn mà các nhà phát triển thường gặp phải với SQL thường liên quan đến việc cố gắng áp đặt một mô hình không quan hệ mô hình dữ liệu trên một sản phẩm cơ sở dữ liệu quan hệ.

Đối với một điều, chúng làm cho việc sử dụng các truy vấn được tham số hóa trở nên tầm thường, bảo vệ bạn khỏi các cuộc tấn công SQL injection. Sử dụng SQL thô, từ góc độ này, rủi ro hơn, tức là dễ mắc lỗi hơn từ góc độ bảo mật. Họ cũng thường trình bày quan điểm hướng đối tượng trên cơ sở dữ liệu của bạn, giúp bạn giảm bớt việc phải thực hiện bản dịch này.

Nghe nói nhiều gần đây? Tôi hy vọng bạn không nhầm lẫn điều này với phong trào NoSql. Theo như tôi biết thì chủ yếu là một số người sử dụng NoSql cho các ứng dụng web có khả năng mở rộng cao và dường như đã quên rằng SQL là một công cụ hiệu quả trong trường hợp không phải là "ứng dụng web có khả năng mở rộng cao".

Công việc kinh doanh lớp trừu tượng chỉ là phân loại sự khác biệt giữa mã Hướng đối tượng và mã dựa trên Bảng - Bộ chẳng hạn như SQL thích nói chuyện. Thông thường, điều này dẫn đến việc viết rất nhiều đĩa lò hơi và mã chuyển tiếp buồn tẻ giữa hai loại. ORM tự động hóa điều này và do đó tiết kiệm thời gian cho những người phản đối kinh doanh.

Đối với lập trình viên SQL có kinh nghiệm, mặt xấu là

• Độ dài
• Như nhiều người đã nói ở đây, SQL là khai báo, có nghĩa là tối ưu hóa không trực tiếp . Nó giống như tập hợp so với đua vòng quanh.
• Các khuôn khổ cố gắng giải quyết tất cả các phương ngữ có thể có và không hỗ trợ các phím tắt của bất kỳ phương ngữ nào trong số chúng
• Không có điều khiển phiên bản dễ dàng.

Đối với những người khác, lý do là

• một số lập trình viên không giỏi về SQL. Có thể là do SQL hoạt động với các tập hợp, trong khi các ngôn ngữ lập trình hoạt động trong mô hình đối tượng hoặc chức năng. Suy nghĩ theo tập hợp (liên hợp, sản phẩm, giao nhau) là một vấn đề khó hiểu mà một số người không có.
• một số hoạt động không tự giải thích: tức là lúc đầu không rõ ràng rằng ở đâu và có bộ lọc các bộ khác nhau.
• có quá nhiều phương ngữ

Mục tiêu chính của các khuôn khổ SQL là giảm việc đánh máy của bạn. Bằng cách nào đó, chúng làm được, nhưng quá thường xuyên chỉ dành cho các truy vấn rất đơn giản. Nếu bạn thử làm điều gì đó phức tạp, bạn phải sử dụng chuỗi và gõ rất nhiều. Các khung công tác cố gắng xử lý mọi thứ có thể, như SQL Alchemy, trở nên quá lớn, giống như một ngôn ngữ lập trình khác.

[cập nhật ngày 26.06.10] Gần đây tôi đã làm việc với mô-đun Django ORM . Đây là khung SQL xứng đáng duy nhất mà tôi đã thấy. Và điều này giúp làm việc với nhiều thứ. Tuy nhiên, cốt liệu phức tạp khó hơn một chút.

SQL không phải là một ngôn ngữ khủng khiếp, nó chỉ đôi khi không chơi tốt với những ngôn ngữ khác.

Ví dụ, nếu bạn có một hệ thống muốn biểu diễn tất cả các thực thể dưới dạng các đối tượng trong một số ngôn ngữ OO hoặc ngôn ngữ khác, thì việc kết hợp điều này với SQL mà không có bất kỳ loại lớp trừu tượng nào có thể trở nên khá cồng kềnh. Không có cách nào dễ dàng để ánh xạ một truy vấn SQL phức tạp vào thế giới OO. Để giảm bớt căng thẳng giữa các thế giới đó, các lớp trừu tượng bổ sung được chèn vào (ví dụ: OR-Mapper).

SQL là một ngôn ngữ thực sự tốt để thao tác dữ liệu. Từ góc độ nhà phát triển, điều tôi không thích với nó là việc thay đổi cơ sở dữ liệu không phá vỡ mã của bạn tại thời điểm biên dịch ... Vì vậy, tôi sử dụng tính năng trừu tượng để thêm tính năng này với giá của hiệu suất và có thể là tính biểu cảm của ngôn ngữ SQL , bởi vì trong hầu hết các ứng dụng, bạn không cần tất cả những thứ mà SQL có.

Lý do khác khiến SQL bị ghét là do cơ sở dữ liệu quan hệ.

Các CAP Định lý trở nên phổ biến:

Bạn có thể muốn những mục tiêu nào từ hệ thống dữ liệu dùng chung?

• Nhất quán mạnh mẽ: tất cả khách hàng đều nhìn thấy cùng một chế độ xem, ngay cả khi có bản cập nhật
• Tính sẵn sàng cao: tất cả các khách hàng có thể tìm thấy một số bản sao của dữ liệu, ngay cả khi có lỗi
• Dung sai phân vùng: các thuộc tính hệ thống vẫn giữ ngay cả khi hệ thống được phân vùng

Định lý nói rằng bạn luôn có thể chỉ có hai trong ba thuộc tính CAP cùng một lúc

Địa chỉ cơ sở dữ liệu quan hệ Tính nhất quán mạnh và Khả năng chịu đựng phân vùng.

Vì vậy, ngày càng có nhiều người nhận ra rằng cơ sở dữ liệu quan hệ không phải là viên đạn bạc, và ngày càng có nhiều người bắt đầu từ chối nó vì tính khả dụng cao, vì tính khả dụng cao làm cho việc mở rộng quy mô theo chiều ngang trở nên dễ dàng hơn. Chia tỷ lệ theo chiều ngang được phổ biến vì chúng ta đã đạt đến giới hạn của định luật Moore , vì vậy cách tốt nhất để chia tỷ lệ là thêm nhiều máy hơn.

Nếu cơ sở dữ liệu quan hệ bị từ chối, SQL cũng bị từ chối.

SQL có nhiều sai sót, như một số áp phích khác ở đây đã chỉ ra. Tuy nhiên, tôi vẫn thích sử dụng SQL hơn nhiều công cụ mà mọi người cung cấp như các lựa chọn thay thế, bởi vì các "đơn giản hóa" thường phức tạp hơn những gì họ được cho là đơn giản hóa.

Giả thuyết của tôi là SQL được phát minh bởi một nhóm những người trượt tuyết xanh tháp ngà. Toàn bộ cấu trúc phi thủ tục. Nghe hay đấy: hãy nói cho tôi biết bạn muốn gì hơn là cách bạn muốn làm. Nhưng trong thực tế, thường dễ dàng hơn nếu chỉ đưa ra các bước. Thông thường, điều này có vẻ giống như cố gắng đưa ra các hướng dẫn bảo dưỡng ô tô bằng cách mô tả cách thức hoạt động của ô tô khi bạn hoàn thành. Vâng, bạn có thể nói: "Tôi muốn chiếc xe một lần nữa nhận được 30 dặm cho mỗi gallon, và để chạy với âm thanh ồn ào này như thế này ... hmmmm ... và vv" Nhưng nó sẽ không được dễ dàng hơn cho mọi người chỉ nói, "Thay thế các bugi"? Và ngay cả khi bạn tìm ra cách diễn đạt một truy vấn phức tạp bằng các thuật ngữ phi thủ tục, cơ sở dữ liệu thường đưa ra một kế hoạch thực thi rất kém hiệu quả để đạt được điều đó.

Và việc xử lý nulls khiến tôi phát điên! Đúng vậy, về mặt lý thuyết, nghe có vẻ tuyệt vời khi ai đó nói, "Này, nếu null nghĩa là chưa biết, thì việc thêm một giá trị chưa biết vào một giá trị đã biết sẽ cho một giá trị chưa biết. Rốt cuộc, theo định nghĩa, chúng tôi không biết giá trị chưa biết là gì . " Về mặt lý thuyết, hoàn toàn đúng. Trên thực tế, nếu chúng tôi có 10.000 khách hàng và chúng tôi biết chính xác số tiền 9.999 nợ chúng tôi nhưng có một số câu hỏi về số tiền nợ của khách hàng cuối cùng và ban giám đốc nói, "Tổng các khoản phải thu của chúng tôi là bao nhiêu?", Vâng, theo toán học chính xác câu trả lời là "Tôi không biết". Nhưng câu trả lời thực tế là "chúng tôi tính toán $ 4,327.287,42 nhưng một tài khoản đang được đề cập nên con số đó không chính xác". Tôi chắc rằng ban lãnh đạo thà đóng cửa nếu không phải là một con số nhất định hơn là một cái nhìn trống rỗng.

Tất cả những gì đã nói, tôi vẫn muốn sử dụng SQL hơn là một số lớp được xây dựng trên SQL, điều đó chỉ tạo ra một tập hợp toàn bộ khác mà tôi cần học và sau đó tôi phải biết rằng cuối cùng điều này sẽ được dịch sang SQL, và đôi khi Tôi chỉ có thể tin tưởng nó để thực hiện bản dịch một cách chính xác và hiệu quả, nhưng khi mọi thứ trở nên phức tạp thì tôi không thể, vì vậy bây giờ tôi phải biết thêm lớp, tôi vẫn phải biết SQL và tôi phải biết nó sẽ dịch như thế nào. để tôi có thể lừa lớp lừa SQL làm điều đúng. Arggh.

• Mọi nhà cung cấp đều mở rộng cú pháp SQL để phù hợp với nhu cầu của họ. Vì vậy, trừ khi bạn đang làm những việc khá đơn giản, mã SQL của bạn không thể di động.

• Cú pháp của SQL không trực giao; ví dụ: các câu lệnh select, insert, update,và deleteđều có cấu trúc cú pháp hoàn toàn khác nhau.

Tôi đồng ý với quan điểm của bạn, nhưng để trả lời câu hỏi của bạn, một điều làm cho SQL trở nên "khủng khiếp" là việc thiếu tiêu chuẩn hóa hoàn toàn T-SQL giữa các nhà cung cấp cơ sở dữ liệu (Sql Server, Oracle, v.v.), điều này khiến cho mã SQL không chắc hoàn toàn di động. Các lớp trừu tượng hóa cơ sở dữ liệu giải quyết vấn đề này, mặc dù với chi phí hiệu suất (đôi khi là rất nghiêm trọng).

Sống với SQL thuần túy thực sự có thể là một địa ngục bảo trì. Đối với tôi, lợi thế lớn nhất của ORM là khả năng cấu trúc lại mã một cách an toàn mà không cần các thủ tục "tái cấu trúc DB" tẻ nhạt. Có các khuôn khổ kiểm tra đơn vị tốt và các công cụ tái cấu trúc cho các ngôn ngữ OO, nhưng tôi vẫn chưa thấy đối tác của Resharper cho SQL, chẳng hạn.

Tất cả các DAL đều có SQL đằng sau hậu trường, và bạn vẫn cần biết nó để hiểu những gì đang xảy ra với cơ sở dữ liệu của bạn, nhưng làm việc hàng ngày với lớp trừu tượng tốt trở nên dễ dàng hơn.

Nếu bạn chưa sử dụng SQL quá nhiều, tôi nghĩ vấn đề chính là thiếu các công cụ dành cho nhà phát triển tốt.

Nếu bạn có nhiều kinh nghiệm với SQL, bạn sẽ cảm thấy thất vọng vì không kiểm soát được kế hoạch thực thi. Đây là một vấn đề cố hữu trong cách SQL được chỉ định cho các nhà cung cấp. Tôi nghĩ SQL cần trở thành một ngôn ngữ mạnh mẽ hơn để thực sự khai thác công nghệ cơ bản (rất mạnh mẽ).

Nhanh chóng, hãy viết cho tôi SQL để phân trang tập dữ liệu hoạt động trong MySQL, Oracle, MSSQL, PostgreSQL và DB2.

Ồ, đúng rồi, SQL chuẩn không xác định bất kỳ toán tử nào để giới hạn số lượng kết quả trả về và bắt đầu từ hàng nào.

Không có tình yêu dành cho SQL vì SQL không tốt về cú pháp, ngữ nghĩa và cách sử dụng hiện tại. Tôi sẽ giải thích:

• cú pháp của nó là một mảnh đạn cobol, tất cả những lời chỉ trích về cobol đều áp dụng ở đây (ở mức độ thấp hơn, công bằng mà nói). Cố gắng trở thành ngôn ngữ tự nhiên như mà không thực sự cố gắng diễn giải ngôn ngữ tự nhiên sẽ tạo ra cú pháp ngẫu nhiên (đó là DROP TABLE hay DROP, UPDATE TABLE, UPDATE hoặc UPDATE IN, DELETE hoặc DELETE FROM ...) và các đặc điểm cú pháp như SELECT (bao nhiêu trang thì nó lấp đầy?)
• ngữ nghĩa cũng có sai sót sâu sắc, Date giải thích nó rất chi tiết, nhưng sẽ đủ lưu ý rằng logic ba giá trị boolean không thực sự phù hợp với đại số quan hệ trong đó một hàng chỉ có thể là một phần của bảng.
• có một ngôn ngữ lập trình làm giao diện chính (và thường là duy nhất) cho cơ sở dữ liệu được chứng minh là một lựa chọn thực sự tồi và nó đã tạo ra một loại lỗi bảo mật mới

Tôi đồng ý với hầu hết các bài viết ở đây rằng cuộc tranh luận về tiện ích của SQL chủ yếu là chủ quan, nhưng tôi nghĩ nó chủ quan hơn về bản chất nhu cầu kinh doanh của bạn.

Như Stefan Steinegger đã chỉ ra, các ngôn ngữ khai báo rất tốt cho việc xác định những gì bạn muốn chứ không phải cách bạn muốn làm. Điều này có nghĩa là các triển khai SQL khác nhau của bạn là phù hợp từ góc độ cấp cao: nghĩa là, nếu tất cả những gì bạn muốn là lấy một số dữ liệu và không có gì khác quan trọng, bạn có thể tự thỏa mãn với việc viết các truy vấn tương đối đơn giản và chọn triển khai SQL điều đó phù hợp với bạn.

Nếu bạn làm việc ở cấp độ "thấp" hơn nhiều và bạn cần tự mình tối ưu hóa tất cả những thứ đó, thì điều đó còn xa lý tưởng. Sử dụng thêm một lớp trừu tượng có thể hữu ích, nhưng nếu những gì bạn thực sự đang cố gắng làm là chỉ định các phương pháp để tối ưu hóa truy vấn, v.v., thì việc thêm người trung gian khi cố gắng tối ưu hóa sẽ hơi phản cảm.

Vấn đề lớn nhất mà tôi gặp phải với SQL cũng giống như các ngôn ngữ "chuẩn hóa" khác, có rất ít tiêu chuẩn thực sự. Tôi gần như muốn học một ngôn ngữ hoàn toàn mới giữa Sybase và MySQL để không bị nhầm lẫn hai quy ước.

Mặc dù SQL hoàn thành công việc nhưng chắc chắn có vấn đề ...

• nó cố gắng đồng thời là mức độ cao và mức độ trừu tượng thấp , và điều đó thật ... kỳ quặc. Có lẽ nó nên có hai hoặc nhiều tiêu chuẩn ở các cấp độ khác nhau.
• đó là một thất bại lớn như một tiêu chuẩn . Rất nhiều điều xảy ra sai lầm khi một tiêu chuẩn hoặc không ổn định trong mọi thứ, yêu cầu quá nhiều triển khai, yêu cầu quá ít hoặc vì lý do nào đó không hoàn thành mục tiêu xã hội một phần là thúc đẩy các nhà cung cấp và người triển khai sản xuất các bản triển khai hoàn chỉnh có thể tương thích một cách nghiêm ngặt. Bạn chắc chắn không thể nói SQL đã làm được điều đó. Xem xét một số tiêu chuẩn khác và lưu ý rằng sự thành công hay thất bại của tiêu chuẩn rõ ràng là một yếu tố của sự hợp tác hữu ích đạt được:
  • RS-232 ( Lỗi , gần như không được chỉ định đủ, ngay cả chân nào truyền và chân nào nhận là tùy chọn, sheesh. Bạn có thể tuân thủ nhưng vẫn không đạt được gì. Cơ hội tương tác thành công: thực sự thấp cho đến khi PC IBM trở thành tiêu chuẩn hữu ích trên thực tế .)
  • IEEE 754-1985 Floating Point ( Xấu , tiếp cận quá mức: không một siêu máy tính hoặc máy trạm khoa học hoặc bộ vi xử lý RISC nào từng áp dụng nó, mặc dù cuối cùng sau 20 năm, chúng tôi đã có thể triển khai nó một cách độc đáo trong HW. Ít nhất thì thế giới cuối cùng cũng phát triển thành công nó.)
  • C89, C99, PCI, USB, Java ( Tốt , dù là tiêu chuẩn hay thông số kỹ thuật, chúng đã thành công trong việc thúc đẩy sự tuân thủ nghiêm ngặt từ hầu hết mọi người và sự tuân thủ đó dẫn đến khả năng tương tác thành công.)
• nó không được chọn làm cơ sở dữ liệu quan trọng nhất trên thế giới . Mặc dù đây là một điểm dữ liệu hơn là một lý do, thực tế là Google Bigtable không phải là SQL và không quan hệ là một loại phản thành tích đối với SQL.

Tôi không thích SQL, nhưng tôi cũng không muốn phải viết nó như một phần của những gì tôi đang phát triển. DAL không phải là về tốc độ đưa ra thị trường - thực ra, tôi chưa bao giờ nghĩ rằng sẽ có một triển khai DAL nhanh hơn các truy vấn trực tiếp từ mã. Nhưng mục tiêu của DAL là trừu tượng hóa . Tính trừu tượng đi kèm với cái giá phải trả, và ở đây là nó sẽ mất nhiều thời gian hơn để thực hiện.

Tuy nhiên, lợi ích là rất lớn. Viết các bài kiểm tra gốc xung quanh mã, sử dụng các lớp biểu cảm, bộ dữ liệu được đánh máy mạnh, v.v. Chúng tôi sử dụng "DAL" trong số các loại, đây là một triển khai DDD thuần túy sử dụng Generics trong C #. Vì vậy, chúng tôi có các kho lưu trữ chung, đơn vị triển khai công việc (giao dịch dựa trên mã) và phân tách hợp lý. Chúng ta có thể làm những việc như mô phỏng bộ dữ liệu của mình mà không cần nỗ lực nhiều và thực sự phát triển trước các triển khai cơ sở dữ liệu. Đã có một khoản chi phí trả trước trong việc xây dựng một khuôn khổ như vậy, nhưng rất hay khi logic kinh doanh lại là ngôi sao của chương trình. Chúng tôi sử dụng dữ liệu như một tài nguyên ngay bây giờ và xử lý nó bằng ngôn ngữ mà chúng tôi đang sử dụng nguyên bản trong mã. Một lợi ích bổ sung của cách tiếp cận này là sự tách biệt rõ ràng mà nó cung cấp. Ví dụ: tôi không còn thấy một truy vấn cơ sở dữ liệu trong một trang web. Có, trang đó cần dữ liệu. Có, cơ sở dữ liệu có liên quan. Nhưng bây giờ, bất kể tôi đang lấy dữ liệu từ đâu, vẫn có một (và duy nhất) nơi để vào mã và tìm nó. Có thể không phải là vấn đề lớn đối với các dự án nhỏ hơn, nhưng khi bạn có hàng trăm trang trong một trang web hoặc hàng chục cửa sổ trong một ứng dụng máy tính để bàn, bạn thực sự có thể đánh giá cao nó.

Là một nhà phát triển, tôi được thuê để thực hiện các yêu cầu của doanh nghiệp bằng cách sử dụng các kỹ năng logic và phân tích của mình - và việc triển khai khuôn khổ của chúng tôi cho phép tôi làm việc hiệu quả hơn bây giờ. Là một người quản lý, tôi muốn các nhà phát triển của mình sử dụng các kỹ năng phân tích và logic của họ để giải quyết vấn đề hơn là viết SQL. Thực tế là chúng ta có thể xây dựng toàn bộ một ứng dụng sử dụng cơ sở dữ liệu mà không cần có cơ sở dữ liệu cho đến khi gần kết thúc chu kỳ phát triển là một điều tuyệt vời. Nó không có nghĩa là một cú đánh chống lại các chuyên gia cơ sở dữ liệu. Đôi khi việc triển khai cơ sở dữ liệu phức tạp hơn giải pháp. SQL (và trong trường hợp của chúng ta, cụ thể là View và Stored Procs) là một điểm trừu tượng nơi mã có thể sử dụng dữ liệu như một dịch vụ. Trong các cửa hàng có sự tách biệt rõ ràng giữa dữ liệu và nhóm phát triển, điều này giúp loại bỏ việc ngồi trong một mô hình giữ để chờ triển khai và thay đổi cơ sở dữ liệu. Các nhà phát triển có thể tập trung vào miền sự cố mà không cần di chuột qua DBA và DBA có thể tập trung vào việc triển khai chính xác mà nhà phát triển không cần nóngay bây giờ .

Nhiều bài viết ở đây dường như lập luận rằng SQL là xấu vì nó không có các tính năng "tối ưu hóa mã" và bạn không có quyền kiểm soát các kế hoạch thực thi.

Điều mà các công cụ SQL giỏi là đưa ra một kế hoạch thực thi cho một lệnh bằng văn bản, hướng tới dữ liệu , nội dung thực tế . Nếu bạn quan tâm đến khía cạnh lập trình của mọi thứ, bạn sẽ thấy rằng có nhiều dữ liệu hơn là byte được chuyển giữa các tầng ứng dụng.