Tôi đã đọc / xem rất nhiều nội dung của Robert C. Martin. Tôi đã bắt gặp anh ta nói rằng SQL là không cần thiết vì các ổ đĩa trạng thái rắn. Khi tôi tìm kiếm các nguồn khác để sao lưu này, tôi nhận được một loạt các bài viết ngẫu nhiên mô tả sự khác biệt về hiệu suất SQL giữa các ổ đĩa cứng và ổ đĩa trạng thái rắn (có liên quan nhưng không phải là những gì tôi đang cố gắng nghiên cứu).

Cuối cùng, tôi không hiểu anh ấy đang cố gắng làm gì. Có phải ông đang nói thay thế SQL bằng các công nghệ No-SQL? Có phải ông đang nói lưu trữ dữ liệu trong các tệp trong một hệ thống tệp? Hay anh ta chỉ muốn mọi người ngừng sử dụng Cơ sở dữ liệu SQL / Quan hệ vì các cuộc tấn công SQLi? Tôi sợ rằng tôi đang thiếu điểm mà anh ấy đang cố gắng thực hiện.

Tôi sẽ cung cấp một số liên kết ở đây để bạn có thể đọc thẳng từ tâm trí của anh ấy:

1. Bàn Bobby
2. Bài giảng kiến ​​trúc sạch

Đầu tiên, ông tuyên bố rằng SQL nên được loại bỏ hoàn toàn khỏi hệ thống.

Giải pháp. Giải pháp duy nhất. Là để loại bỏ SQL hoàn toàn khỏi hệ thống. Nếu không có công cụ SQL, thì không thể có các cuộc tấn công SQLi.

Và mặc dù anh ấy nói về việc thay thế SQL bằng API, tôi KHÔNG nghĩ anh ấy có nghĩa là đặt SQL đằng sau một API vì câu nói trước đó và những gì anh ấy đã nói trước đó trong bài viết.

Các khung không xử lý vấn đề; ...

Lưu ý bên lề: Khi nói SQL, tôi khá chắc chắn Robert có nghĩa là hầu hết các cơ sở dữ liệu quan hệ. Có lẽ không phải tất cả nhưng hầu hết. Trong mọi trường hợp, hầu hết mọi người đang sử dụng SQL. vì thế...

Nếu SQL không được sử dụng để duy trì dữ liệu, vậy thì chúng ta phải sử dụng cái gì?

Trước khi trả lời, tôi cũng cần lưu ý. Robert nhấn mạnh rằng các ổ đĩa trạng thái rắn nên thay đổi các công cụ mà chúng ta sử dụng để duy trì dữ liệu. Câu trả lời của Søren D. Ptæus chỉ ra điều này.

Tôi cũng phải trả lời nhóm "nhưng toàn vẹn dữ liệu". Sau khi nghiên cứu thêm, Robert nói rằng chúng ta nên sử dụng cơ sở dữ liệu giao dịch như datomic . Sau đó CRUD biến thành CR (tạo và đọc) và các giao dịch SQL biến mất hoàn toàn. Toàn vẹn dữ liệu là tất nhiên quan trọng.

Tôi không thể tìm thấy một câu hỏi bao gồm tất cả những điều này. Tôi đoán tôi đang tìm giải pháp thay thế phù hợp với hướng dẫn của Robert. Datomic là một nhưng là nó? Những lựa chọn khác phù hợp với những hướng dẫn này? Và họ thực sự làm việc tốt hơn với các ổ đĩa trạng thái rắn?

Bob Martin rõ ràng là phóng đại để làm cho quan điểm của mình rõ ràng hơn. Nhưng quan điểm của anh ấy là gì?

Có phải anh ta chỉ muốn mọi người ngừng sử dụng Cơ sở dữ liệu SQL / Quan hệ vì các cuộc tấn công SQLi?

Theo hiểu biết của tôi, trong bài đăng trên blog đó (liên kết đầu tiên của bạn) Martin cố gắng thuyết phục mọi người ngừng sử dụng SQL, nhưng không phải là cơ sở dữ liệu quan hệ. Đây là hai điều khác nhau .

SQL là một ngôn ngữ cực kỳ mạnh mẽ và nó được chuẩn hóa ở một mức độ nào đó. Nó cho phép tạo các truy vấn và lệnh phức tạp một cách rất nhỏ gọn, theo kiểu dễ đọc, dễ hiểu, dễ học. Nó không phụ thuộc vào ngôn ngữ lập trình khác, vì vậy hầu hết các lập trình viên ứng dụng đều có thể sử dụng được, bất kể họ thích Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP hay thứ gì khác.

Tuy nhiên, sức mạnh này phải trả giá : viết các truy vấn / lệnh SQL an toàn khó hơn viết các lệnh không an toàn. API an toàn sẽ giúp bạn dễ dàng tạo các truy vấn an toàn "theo mặc định". Những người có khả năng không an toàn nên cần nhiều nỗ lực tinh thần hơn hoặc ít nhất là nhiều hơn. Đó là IMHO tại sao Martin lại phát cuồng chống lại SQL ở dạng hiện tại.

Vấn đề không phải là mới và có các API an toàn hơn SQL tiêu chuẩn để truy cập cơ sở dữ liệu quan hệ. Ví dụ: tất cả những người lập bản đồ OR mà tôi biết đang cố gắng cung cấp API như vậy (mặc dù chúng thường được thiết kế cho các mục tiêu chính khác). Các biến thể SQL tĩnh khiến bạn khó tạo ra bất kỳ truy vấn động nào với dữ liệu đầu vào không được xác thực (và đó không phải là một phát minh mới: SQL nhúng, thường sử dụng SQL tĩnh, khoảng 30 năm tuổi).

Thật không may, tôi không biết bất kỳ API nào linh hoạt, chuẩn hóa, trưởng thành, độc lập với ngôn ngữ và cũng mạnh mẽ như SQL, đặc biệt là SQL động. Đó là lý do tại sao tôi có một số nghi ngờ về đề xuất "không sử dụng SQL" của Martin như một cách giải quyết vấn đề thực tế. Vì vậy, hãy đọc bài viết của anh ấy như một suy nghĩ đi đúng hướng, không phải là một "thực hành tốt nhất" mà bạn có thể theo dõi một cách mù quáng từ ngày mai.

Ý kiến ​​của Bob Martin chỉ là vậy; ý kiến ​​của một người đàn ông.

Một lập trình viên dự kiến ​​sẽ hiểu hệ thống mà anh ta viết đủ tốt để thực hiện sự quan tâm hợp lý về bảo mật và hiệu suất của nó. Điều đó có nghĩa là, nếu bạn đang nói chuyện với cơ sở dữ liệu SQL, bạn sẽ làm những gì trang web của Bobby Bảng nói để làm: bạn vệ sinh dữ liệu đầu vào của mình. Điều đó có nghĩa là bạn đặt cơ sở dữ liệu SQL của mình trên một máy hứa hẹn hiệu năng đầy đủ. Có những cách rất nổi tiếng và được hiểu rõ để làm những việc này, và trong khi chúng không đảm bảo an ninh tuyệt đối hoặc hiệu suất lý tưởng, thì không có gì khác.

Khẳng định rằng chúng tôi không cần SQL nữa vì hiện tại chúng tôi có SSD chỉ là thông số kỹ thuật. SQL không được phát minh vì ổ cứng tốc độ cao chưa tồn tại; nó được phát minh bởi vì chúng tôi cần một cách tiêu chuẩn công nghiệp để thể hiện các khái niệm truy xuất dữ liệu. Các hệ thống cơ sở dữ liệu quan hệ có nhiều phẩm chất khác bên cạnh tốc độ và bảo mật khiến chúng trở nên lý tưởng cho các hoạt động kinh doanh; đặc biệt là ACID . Tính toàn vẹn dữ liệu ít nhất cũng quan trọng như tốc độ hoặc bảo mật và nếu bạn không có nó, vậy thì điểm nào để bảo mật dữ liệu xấu hoặc truy xuất dữ liệu đó càng nhanh càng tốt?

Trước khi bạn lấy sự cuồng loạn của một người làm phúc âm, tôi khuyên bạn nên tìm hiểu về ứng dụng và bảo mật hệ thống và hiệu suất theo cách riêng của họ, chứ không phải bằng cách đọc các bài báo ngẫu nhiên trên Internet. Có nhiều thứ hơn để bảo mật, hiệu suất và thiết kế hệ thống mạnh mẽ hơn là chỉ đơn giản là "tránh công nghệ này".

Chúng tôi không cấm dao nhà bếp vì một vài người không may mắn đã vô tình cắt ngón tay của họ với họ.

Anh ấy thực sự đang nói gì?

Có phải ông đang nói thay thế SQL bằng các công nghệ No-SQL?

TL; DR: Có (sắp xếp)

Trong một cuộc nói chuyện gần đây hơn so với cuộc trò chuyện mà bạn liên kết về cơ bản cùng một chủ đề, ông nói: "Cơ sở dữ liệu là một chi tiết. Tại sao chúng ta có cơ sở dữ liệu?" .

Ông tuyên bố cơ sở dữ liệu là để giúp truy cập dữ liệu từ các đĩa quay dễ dàng hơn, nhưng trong tương lai "[...] sẽ không có đĩa" nhờ vào công nghệ mới và cái mà ông gọi là "RAM liên tục" và điều đó sẽ dễ dàng hơn lưu trữ dữ liệu bằng cách sử dụng các cấu trúc mà các lập trình viên sử dụng, chẳng hạn như hashtables hoặc cây.

Ông tiếp tục dự đoán rằng các cơ sở dữ liệu quan hệ trên tổng thể sẽ biến mất phần lớn do sự cạnh tranh mới của họ:

Nếu tôi là Oracle, tôi sẽ khá sợ hãi vì lý do cho sự tồn tại của tôi đang bốc hơi từ bên dưới tôi. [...] Lý do cho cơ sở dữ liệu tồn tại đang biến mất.

Có lẽ sẽ có một số bảng quan hệ tồn tại, nhưng bây giờ có một số cạnh tranh lành mạnh .

Vì vậy, đối với anh ta, không chỉ về việc tiêm SQL, mặc dù anh ta cho rằng SQL không hoàn toàn sai sót về vấn đề này .

Ghi chú của tác giả:

Các tuyên bố trong bài viết này chỉ là trích dẫn để hiểu quan điểm của Robert C. Martin về chủ đề này và không đại diện cho ý kiến ​​của tác giả. Để có quan điểm khác biệt hơn, hãy xem câu trả lời của Robert Harvey .

SQL là một chi tiết. Kiến thức về một chi tiết không nên lan truyền.

Vì SQL được sử dụng ở càng nhiều nơi trong mã của bạn, mã của bạn càng trở nên phụ thuộc vào nó.

Khi bạn tìm hiểu càng nhiều thủ thuật SQL, bạn sẽ giải quyết được nhiều vấn đề hơn bằng cách sử dụng SQL. Điều này có nghĩa là việc chuyển sang API khác để duy trì liên quan đến nhiều thứ hơn là chỉ dịch. Bạn phải giải quyết vấn đề mà bạn không nhận ra mình đã có.

Bạn chạy vào điều này thậm chí chuyển đổi giữa các cơ sở dữ liệu. Một cung cấp tính năng whizzbang 5 lạ mắt, do đó bạn chỉ sử dụng nó ở một số nơi để tìm hiểu tính năng whizzbang 5 là độc quyền và bây giờ bạn có vấn đề cấp phép sẽ tốn rất nhiều tiền. Vì vậy, bạn thực hiện rất nhiều công việc đào bới khắp mọi nơi bạn đã sử dụng tính năng 5 và tự mình giải quyết vấn đề để tìm hiểu sau này bạn cũng đang sử dụng tính năng whizzbang 3.

Một trong những điều làm cho Java trở nên di động là các tính năng nhất định của CPU không có sẵn. Nếu chúng có sẵn tôi sẽ sử dụng chúng. Và đột nhiên có CPU mà mã Java của tôi không hoạt động được vì chúng không có các tính năng đó. Nó giống với các tính năng cơ sở dữ liệu.

Đó là tất cả để dễ dàng hy sinh sự độc lập của bạn mà không nhận ra điều đó. SQL là một sự lựa chọn không phải là nhất định. Nếu bạn đưa ra quyết định sử dụng SQL thì hãy đặt nó ở một nơi. Làm cho nó theo một cách có thể được tạo ra.

Thực tế là SQL có vấn đề về bảo mật và việc chúng ta chuyển sang các mô hình bộ nhớ liên tục không có nghĩa là SQL sẽ bị tiêu diệt. Nó chỉ lái xe về nhà mà nó là một sự lựa chọn. Nếu bạn muốn giữ quyền lựa chọn đó, bạn phải thực hiện công việc.

Điều đáng chú ý là phong trào cơ sở dữ liệu của thập niên 80 và chú Bob có một lịch sử khá khó chịu. Anh ấy đã giải quyết tất cả các vấn đề của mình với một hệ thống tệp phẳng khi quản lý buộc một quản trị viên cơ sở dữ liệu vào cuộc sống của anh ấy. Sự kiện này đã đẩy anh ta vào sự nghiệp tư vấn xuất sắc của mình. (Anh ấy kể câu chuyện này trong một trong những cuốn sách đầu tiên của mình, quên đi) Anh ấy biết cách giải quyết vấn đề mà không cần DB và có chút kiên nhẫn cho những người hành động như sử dụng chúng là một điều được đưa ra.

Anh ta cũng kể một câu chuyện về việc tắt DB vào một ứng dụng cho đến phút cuối cùng khi khách hàng yêu cầu và thêm nó trong một ngày như một tính năng tùy chọn. Tôi đoán là anh ấy thấy cách mà hầu hết chúng ta sử dụng DB như một chứng nghiện. Anh ấy đang cố gắng chỉ cho chúng tôi cách từ bỏ thói quen.

Trích dẫn từ trích dẫn đầu tiên của bạn là (nhấn mạnh của tôi),

Giải pháp. Giải pháp duy nhất. Là để loại bỏ SQL hoàn toàn khỏi hệ thống . Nếu không có công cụ SQL, thì không thể có các cuộc tấn công SQLi.

Điều gì sẽ thay thế SQL? Tất nhiên là có API! Và KHÔNG phải là API sử dụng ngôn ngữ văn bản. Thay vào đó, một API sử dụng một tập hợp các cấu trúc dữ liệu và lời gọi hàm thích hợp để truy cập dữ liệu cần thiết.

Các rant chống lại việc cho phép các lập trình viên ứng dụng sử dụng SQL.

Cách khắc phục được đề xuất là cho phép họ sử dụng API thay thế: đó không phải là SQL và không cho phép tiêm.

IMO, ví dụ về các API như vậy có thể bao gồm:

• http://bobby-tables.com/csharp gợi ý các lập trình viên C # có thể sử dụng API ADO.NET.

  Đó không phải là một ví dụ hoàn hảo vì ADO.NET là API rộng hoặc sâu (nghĩa là mạnh mẽ hoặc có mục đích chung), cũng cho phép người dùng nhập SQL thô (hoặc raw-ish).

• Một số nhà phát triển SQL hoặc quản trị viên cơ sở dữ liệu đề xuất rằng nên cấu hình cơ sở dữ liệu để nó chỉ cho phép truy cập thông qua (một số lượng hạn chế các thủ tục được lưu trữ chuyên nghiệp) và các nhà phát triển ứng dụng không được phép viết các truy vấn SQL (nguy hiểm) của riêng họ

• Một cách khác để "loại bỏ SQL khỏi hệ thống" là đặt cơ sở dữ liệu (hiển thị SQL) trên một số hệ thống khác , được truy cập thông qua API REST hoặc tương tự.

Vì vậy, IMO, giải pháp tổng thể hoặc hệ thống vẫn có thể sử dụng cơ sở dữ liệu (đặc biệt là khi một công cụ cơ sở dữ liệu thực hiện các thuộc tính ACID hữu ích và có quy mô tốt, v.v., có thể thật ngu ngốc khi cố gắng làm mà không cần hoặc viết một ứng dụng dành riêng cho ứng dụng).

Các yêu cầu của rant được thỏa mãn nếu API SQL của cơ sở dữ liệu bị ẩn khỏi các nhà phát triển ứng dụng, đằng sau một số API khác (ví dụ: ADO, có lẽ là ORM, dịch vụ Web hoặc bất cứ điều gì).

Nói chung, tôi cho rằng nó có nghĩa là có một DAL dành riêng cho ứng dụng ("lớp truy cập dữ liệu" hoặc "lớp trừu tượng hóa cơ sở dữ liệu"). Một DAL cách ly ứng dụng khỏi các chi tiết về cách thức và nơi dữ liệu được lưu trữ và / hoặc tìm nạp. DAL có thể hoặc không thể được thực hiện bằng cơ sở dữ liệu SQL.

Mọi người dường như đang trả lời câu hỏi này từ quan điểm bảo mật hoặc với ống kính SQL.

Tôi thấy một bài giảng của Robert Martin nơi ông kể lại rằng là các lập trình viên, chúng tôi sử dụng nhiều cấu trúc dữ liệu khác nhau tối ưu cho các chương trình cụ thể của chúng tôi. Vì vậy, thay vì lưu trữ phổ biến tất cả dữ liệu trong cấu trúc bảng, chúng ta nên lưu trữ dữ liệu của mình trong bảng băm, cây, v.v để có thể lấy dữ liệu và nhảy ngay vào chương trình.

Tôi giải thích thông điệp của anh ấy khi chỉ nói rằng chúng ta nên đưa ra các giả định hiện tại về việc lưu trữ liên tục trong giây lát để xem xét các khả năng khác trong tương lai so với định dạng bảng SQL cũ. SSD là một giải pháp ứng cử viên, nhưng không phải là giải pháp duy nhất.

Trên thực tế, anh ta không sử dụng cơ sở dữ liệu và SQL - khá rõ ràng. Tài liệu tham khảo đầu tiên là một vấn đề được biết rõ, tài liệu tham khảo thứ hai phát ra âm thanh như một lời ca ngợi. Mặc dù, tôi đang giải thích nó là có lý do chính đáng để sử dụng cơ sở dữ liệu và không sử dụng SQL. Từ quan điểm của tôi điều này thậm chí không phải là lời khuyên hợp lý.

Thật không may, ví dụ anh ta đang sử dụng là một ví dụ nổi tiếng với một giải pháp nổi tiếng mà sau đó anh ta chỉ ra. Nó thường xuất hiện khi một lập trình viên không nhận ra mình đang làm gì. Ví dụ: xây dựng các chuỗi chứa SQL như:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

như trái ngược với

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

Đây là một ví dụ DBI perl cho mã ruby ​​trên đường ray. Mã đường ray mà anh ta cung cấp rất dễ nhầm lẫn giữa an toàn và không an toàn. Giống như nhiều ORM ẩn những gì SQL bên dưới và thường thì bạn đang xử lý một giao diện xây dựng và thực thi sql cho bạn. Điều này có giống như những gì API sẽ làm cho bạn không?

Giải thích của tôi về tài liệu tham khảo đầu tiên là ông đang gợi ý rằng chúng ta nên thay thế một vấn đề nổi tiếng có giải pháp nổi tiếng.

Thật không may là anh ta không đề cập rằng nếu điều này được thực hiện một cách chính xác, nó sẽ làm cho mã dễ viết hơn và dễ đọc hơn, mặc dù nếu nó được thực hiện tốt, nó thực sự có thể khó viết hơn và khó đọc hơn. Ngoài ra, ông không đề cập đến việc SQL thực sự rất dễ đọc và làm những gì bạn thường mong đợi nó sẽ làm.

Anh ta đúng một phần, cuối cùng chúng ta sẽ có một bộ nhớ lớn và nhanh vô hạn và một bộ xử lý cực kỳ nhanh. Cho đến khi chúng tôi thoát ra khỏi vật lý hiện tại hạn chế tính toán, anh ta không đúng.

Có đĩa quay là một điều của quá khứ, và bây giờ chúng tôi sử dụng SSD. Đĩa hoạt động với khoảng ~ 10 mili giây mỗi lần truyền dữ liệu, SSD hoạt động với thời gian truy cập dữ liệu ~ 0,5 mili giây (500 microsec). RAM ở mức 100 nano giây, bộ xử lý hoạt động với tốc độ 100 giây pico giây. Đây là trung tâm của lý do tại sao chúng ta cần cơ sở dữ liệu. Cơ sở dữ liệu quản lý việc truyền dữ liệu giữa các đĩa quay hoặc SSD với bộ nhớ chính. Sự ra đời của SSD chưa loại bỏ nhu cầu về cơ sở dữ liệu.

Câu trả lời

Có phải anh ta chỉ muốn mọi người ngừng sử dụng Cơ sở dữ liệu SQL / Quan hệ vì các cuộc tấn công SQLi?

Bài viết 'Bảng Bobby' dường như gợi ý rằng, điều này và chính nó là một lý do để không sử dụng SQL:

Giải pháp. Giải pháp duy nhất. Là để loại bỏ SQL hoàn toàn khỏi hệ thống. Nếu không có công cụ SQL, thì không thể có các cuộc tấn công SQLi.

Anh ta có thể có những lý do khác mà anh ta thảo luận ở nơi khác. Tôi không biết vì tôi không thực sự đọc nhiều thứ của anh ấy.

Giải mã

Phần này không thực sự là một câu trả lời, nhưng tôi nghĩ rằng câu hỏi về giá trị của SQL thú vị hơn nhiều (cũng như những người khác, rõ ràng.)

Tôi đã có nhiều kinh nghiệm sử dụng SQL và tôi nghĩ rằng tôi hiểu rõ về điểm mạnh và điểm yếu của nó. Cảm nhận cá nhân của tôi là nó đã bị lạm dụng và lạm dụng, nhưng ý tưởng rằng chúng ta không bao giờ nên sử dụng nó là loại ngớ ngẩn. Ý tưởng rằng chúng ta phải chọn 'SQL luôn' hoặc 'SQL không bao giờ' là một sự phân đôi sai.

Theo như SQL tiêm là một đối số cho việc không sử dụng SQL, điều đó thật buồn cười. Đây là một vấn đề được hiểu rõ với một giải pháp khá đơn giản. Vấn đề với lập luận này là SQLi không phải là lỗ hổng duy nhất tồn tại. Nếu bạn nghĩ rằng việc sử dụng API JSON làm cho bạn an toàn, bạn sẽ gặp bất ngờ lớn.

Tôi nghĩ rằng mọi nhà phát triển nên xem video này có tiêu đề "Thứ sáu ngày 13: Tấn công JSON - Alvaro Muñoz & Oleksandr Mirosh - AppSecUSA 2017"

Nếu bạn không có thời gian hoặc thiên hướng để xem qua nó, thì đây là ý chính: Rất nhiều thư viện giải nén JSON có các lỗ hổng thực thi mã từ xa. Nếu bạn đang sử dụng XML, bạn còn phải lo lắng nhiều hơn nữa. Cấm SQL từ kiến ​​trúc của bạn sẽ không làm cho hệ thống của bạn an toàn.

Tôi chỉ muốn giải quyết một tuyên bố ngắn:

Hay anh ta chỉ muốn mọi người ngừng sử dụng Cơ sở dữ liệu SQL / Quan hệ vì các cuộc tấn công SQLi?

Không. Đó là một giả định sai. Chúng tôi không thể nói rằng chúng tôi phải ngừng sử dụng xe hơi, bởi vì họ chịu trách nhiệm về những người chết vì tai nạn xe hơi. Theo cùng một cách, các cơ sở dữ liệu SQL / quan hệ (hoặc bất cứ thứ gì khác trong ngữ cảnh này, chẳng hạn như RDBMS) không chịu trách nhiệm đối với tải trọng SQL độc hại mà kẻ tấn công có thể thực hiện trên ứng dụng web của bạn. Tôi chắc chắn rằng tác giả không có ý đó, bởi vì có toàn bộ bảng cheat ngăn chặn tiêm SQL cho mục đích này.

Vấn đề của Martin dường như là với các lập trình viên xây dựng SQL động trực tiếp từ đầu vào của người dùng, đại loại như (tha thứ cho tôi, tôi chủ yếu là lập trình viên C và C ++):

sprintf( query, "select foo from bar where %s;", user_input );

đó hoàn toàn là một công thức cho chứng ợ nóng (do đó là dải Bobby Bảng ). Bất kỳ lập trình viên nào đặt mã như thế trong một hệ thống sản xuất đều xứng đáng là một paddlin '.

Bạn có thể giảm thiểu (nếu không loại bỏ hoàn toàn) vấn đề bằng cách sử dụng các tuyên bố đã chuẩn bị và vệ sinh đúng cách các đầu vào của bạn. Nếu bạn có thể ẩn SQL đằng sau một API để các lập trình viên không trực tiếp xây dựng các chuỗi truy vấn, thì càng tốt (đó là một phần của những gì Martin ủng hộ).

Nhưng để loại bỏ hoàn toàn SQL, tôi không nghĩ đó là thực tế hay mong muốn. Các mô hình quan hệ rất hữu ích , đó là lý do tại sao chúng tồn tại ở vị trí đầu tiên và SQL có lẽ là giao diện tốt nhất để làm việc với các mô hình quan hệ.

Như mọi khi, đó là vấn đề sử dụng công cụ phù hợp cho công việc. Nếu ứng dụng giỏ hàng của bạn không cần mô hình quan hệ đầy đủ, thì đừng sử dụng mô hình quan hệ (có nghĩa là bạn sẽ không cần sử dụng SQL). Đối với những lần bạn cần một mô hình quan hệ, thì bạn gần như chắc chắn sẽ làm việc với SQL.

Hai nguồn bạn liên kết truyền tải các thông điệp khác nhau:

Bài đăng trên blog nói rằng logic truy cập dữ liệu không nên tồn tại dưới dạng văn bản trong thời gian chạy, vì sợ rằng nó sẽ bị trộn lẫn với đầu vào của người dùng không đáng tin cậy. Đó là, bài viết trên blog lên án các truy vấn bằng cách nối các chuỗi.

Bài giảng thì khác. Sự khác biệt đầu tiên là về giọng điệu: Bài giảng suy đoán và gọi vào câu hỏi, nhưng không lên án. Anh ta không nói rằng cơ sở dữ liệu là xấu, nhưng thách thức chúng ta tưởng tượng sự bền bỉ mà không có cơ sở dữ liệu. Ông lập luận rằng trong 30 năm kể từ khi cơ sở dữ liệu quan hệ trở nên phổ biến, nhiều thứ đã thay đổi và nổi bật là hai thứ có thể ảnh hưởng đến sự lựa chọn công nghệ bền bỉ của chúng tôi:

• dung lượng lưu trữ đã tăng thêm khoảng 1 triệu - với mức giá tương đương! Do đó, việc bảo tồn lưu trữ là ít cần thiết hơn và đặc biệt, không còn cần thiết phải xóa. Bằng cách sử dụng lưu trữ chỉ chắp thêm, kiểm soát đồng thời có thể được đơn giản hóa vì khóa đọc là không cần thiết. Điều này có thể làm giảm nhu cầu giao dịch.
• thời gian truy cập đã giảm, vì hầu hết các bộ dữ liệu hiện nay đều phù hợp với RAM, giúp giảm đáng kể độ trễ đọc.

Những hoàn cảnh thay đổi này có làm thay đổi công nghệ kiên trì tối ưu không? Thật thú vị, chú Bob không nói - có lẽ bởi vì ông cảm thấy không có câu trả lời nào là đúng cho tất cả các chương trình. Đó là lý do tại sao anh ấy cảnh báo chúng tôi coi sự lựa chọn của chúng tôi về công nghệ bền bỉ như một chi tiết thay vì bảo quản nó thành những phiến đá và truyền lại nó như là sự khôn ngoan nhận được cho các đồng nghiệp của chúng tôi.

Có sự thay thế tồn tại?

Viết logic truy cập dữ liệu mà không có chuỗi là hoàn toàn có thể. Trong vùng đất Java, bạn có thể sử dụng QueryDSL , trong đó các truy vấn được mô tả bằng API thông thạo an toàn loại được tạo từ lược đồ cơ sở dữ liệu của bạn. Một truy vấn như vậy có thể trông như sau:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Như bạn có thể thấy, logic truy vấn không được biểu thị dưới dạng Chuỗi, phân tách rõ ràng cấu trúc tin cậy của truy vấn khỏi các tham số không đáng tin cậy (và tất nhiên, QueryDSL không bao giờ bao gồm các tham số vào văn bản truy vấn, nhưng sử dụng các câu lệnh được chuẩn bị để phân tách truy vấn cho các tham số của nó ở mức JDBC). Để đạt được SQL SQL với QueryDSL, bạn phải viết trình phân tích cú pháp của riêng mình để phân tích một chuỗi và dịch nó thành một cây cú pháp và ngay cả khi bạn đã làm điều đó, có lẽ bạn sẽ không thêm hỗ trợ cho những thứ khó chịu như select ... into file. Nói tóm lại, QueryDSL làm cho việc tiêm SQL không thể thực hiện được, đồng thời cũng cải thiện năng suất của lập trình viên và tăng khả năng tái cấu trúc an toàn. Ngăn chặn rủi ro lớn nhất đối với bảo mật ứng dụng web, đã tồn tại đủ lâu để sinh ra các trò đùa đang chạyvà tăng năng suất của nhà phát triển? Tôi dám nói rằng nếu bạn vẫn viết các truy vấn dưới dạng chuỗi, bạn đang làm sai.

Đối với các lựa chọn thay thế cho các cơ sở dữ liệu quan hệ, thật tò mò khi biết rằng kiểm soát đồng thời đa phiên bản của postgres chính xác là loại cấu trúc dữ liệu chỉ có phụ lục mà chú Bob đang nói đến, mặc dù có lẽ ông đang nghĩ nhiều hơn về các cửa hàng sự kiện và nguồn cung cấp sự kiện mô hình nói chung, cũng phù hợp độc đáo với khái niệm giữ trạng thái hiện tại trong RAM.