Có điều gì đột phá về NoQuery không? [đóng cửa]

Tôi là một anh chàng Cơ sở dữ liệu quan hệ rất vững chắc và hiểu tất cả các dạng của dạng bình thường thứ 3, đánh giá cao gốc rễ lý thuyết tập đại số của SQL và có thể có thể quan hệ hóa một trái tim tan vỡ (hoặc không).

Tôi chưa tìm ra cấu trúc cơ sở dữ liệu quan hệ CHO những đêm hẹn hò với vợ tôi, nhưng tôi đã nghĩ về các dự án cơ sở dữ liệu quan hệ vào những đêm hẹn hò với vợ tôi ..

Bây giờ tôi đang nghe về NoQuery và đang nghiên cứu nó. Theo đuổi, có bất cứ điều gì về NoQuery là đột phá, tiểu thuyết toán học hay "bạn không thực sự cần phải sắp xếp dữ liệu của mình một cách liên quan, cách tiếp cận này dễ dàng hơn nhiều"?

Có phải NoQuery giống như một siêu vỏ cho cấu trúc dữ liệu? Trong tâm trí của tôi, dữ liệu cuối cùng phải có cấu trúc để được truy xuất và việc truy xuất phải được xác định theo một ngôn ngữ nào đó.

NoQuery mang tính tiến hóa hơn là cách mạng. Về cơ bản, nó kết hợp các ý tưởng hiện có về "lưu trữ cơ sở dữ liệu bên ngoài" với "sử dụng các cấu trúc dữ liệu quen thuộc, không phải các bảng quan hệ".

Có nhiều loại cơ sở dữ liệu hơn quan hệ, ví dụ cơ sở dữ liệu phân cấp . Mặc dù cổ xưa theo các tiêu chuẩn ngày nay, nó đã kết nối thực sự tốt với các cấu trúc dữ liệu của dữ liệu của nó (ví dụ: các bản ghi COBOL ). Vấn đề là, dữ liệu trong cơ sở dữ liệu được mô hình hóa chặt chẽ với cách các bản ghi được trình bày trong các ngôn ngữ lập trình sử dụng chúng.

Chuyển nhanh sang phát minh cơ sở dữ liệu quan hệ , trong đó cuối cùng cơ sở dữ liệu tách biệt mối quan tâm và, khi được chuẩn hóa đúng cách, là một cách tuyệt vời để hình dung hầu hết các loại dữ liệu và mối quan hệ giữa dữ liệu. Nó thực sự dễ hiểu so với các loại cơ sở dữ liệu khác. Tuy nhiên, điều mà nó hoàn toàn thất bại là lưu trữ dữ liệu theo cách phản chiếu các đối tượng và các lớp trong một chương trình. Do đó, việc phát minh ra ánh xạ quan hệ đối tượng . Nói cách khác, thiết kế cơ sở dữ liệu thực sự là một trở ngại cho thiết kế chương trình sử dụng nó, đó là lý do tại sao chúng ta cần các thư viện ORM như Hibernate. Trong khi sạch sẽ và nhất quán, luôn có sự nghi ngờ dai dẳng trong đầu tôi rằng có gì đó không hoàn toàn đúng ở đó.

Điều này đã tạo ra thêm hai loại cơ sở dữ liệu, cơ sở dữ liệu đối tượng và NoQuery .

Cả hai đều cố gắng giải quyết các vấn đề được giới thiệu bởi các cơ sở dữ liệu quan hệ trong khi không cho chúng ta thấy sự kinh hoàng của các cơ sở dữ liệu phân cấp. Dữ liệu vẫn được đặt trong các kho lưu trữ gần giống với các bảng, nhưng thực tế lại giống như các cấu trúc dữ liệu lập trình hơn là các bảng quan hệ. Mặc dù cơ sở dữ liệu đối tượng tuân theo các quy tắc được xác định rõ ràng, nhưng sự hiểu biết của tôi là NoQuery khá độc đoán. Ví dụ, một bảng có thể được hiển thị dưới dạng bảng băm hoặc mảng. Không có một cách dễ dàng, được xác định rõ ràng để truy vấn chúng bằng cách sử dụng một công cụ tùy ý tương tự như Oracle SQL Developer hoặc SQL Server Management Studio .

Ý tưởng là người ta có thể định nghĩa các cấu trúc dữ liệu dễ dàng tìm kiếm trong mã, thay vì ghép các truy vấn SQL phù hợp hơn với công cụ cơ sở dữ liệu SQL thay vì thể hiện truy vấn mà người ta mong muốn. Ví dụ, các kết quả mờ hoặc một phần khó khăn hơn và hoạt động kém hơn trong cơ sở dữ liệu quan hệ, trong khi cơ sở dữ liệu NoQuery có thể có cấu trúc được tối ưu hóa cho tìm kiếm như vậy và hoàn thành trong một phần nhỏ thời gian.

Có các ngôn ngữ để truy vấn NoQuery. Tuy nhiên, không có ngôn ngữ phổ quát như SQL dành cho cơ sở dữ liệu quan hệ.

Chỉnh sửa muộn:

Mặc dù tôi đã đủ quen thuộc với cơ sở dữ liệu NoQuery, nhưng câu hỏi này là động lực để tôi mua một cuốn sách chất lượng về chủ đề này và bắt đầu đọc nó với mục tiêu cuối cùng là trở thành một chuyên gia thực sự về chủ đề này. Các ý kiến ​​còn lại được dựa trên NoQuery chưng cất: Hướng dẫn ngắn gọn về Thế giới mới nổi của sự tồn tại của Polyglot của Pramod Sadalage và Martin Fowler .

Các tác giả tuyên bố rằng các cơ sở dữ liệu quan hệ không mở rộng tốt cho các cụm có khả năng phục vụ dữ liệu cần thiết cho các trang web như Amazon và Google: NoQuery được phát triển để phù hợp với phân khúc này, giúp thư giãn tính đồng thời và độ bền trong ACID để cung cấp số lượng truy vấn lớn. phần lớn sử dụng dữ liệu tĩnh (do đó, các giao dịch ACID không quan trọng).

Hơn nữa, họ cho rằng cơ sở dữ liệu NoQuery hoạt động mà không có lược đồ (trang 10) cho phép cơ sở dữ liệu NoQuery sửa đổi cấu trúc dữ liệu dễ dàng hơn. Tôi không chắc chắn rằng sự hiện diện hay vắng mặt của một lược đồ chính thức có liên quan đến vấn đề này, vì cơ sở dữ liệu SQL cũng cho phép sửa đổi các lược đồ. Bất kể, hai tác giả nổi tiếng đưa ra tuyên bố vì vậy nó là giá trị kiểm tra.

Tôi tin rằng cả hai điểm chính này chỉ phục vụ để thực thi quan điểm chính của tôi rằng NoQuery là tiến hóa, không mang tính cách mạng. Họ vẫn lưu trữ dữ liệu và thực hiện các cải tiến gia tăng về quy mô và khả năng sửa đổi. Họ cũng đưa ra quan điểm rằng NoQuery không tìm cách chiếm đoạt cơ sở dữ liệu quan hệ như là vua lưu trữ dữ liệu, chỉ cung cấp một phương tiện lưu trữ dữ liệu thay thế cho các loại dữ liệu cần mở rộng và biến đổi theo cách mà họ tin rằng cơ sở dữ liệu không hỗ trợ đủ tốt.

Tôi nghĩ rằng bạn chắc chắn muốn xem bài báo này của Erik Meijer & Gavin Bierman, với tiêu đề "Trái với niềm tin phổ biến, SQL và NoQuery thực sự chỉ là hai mặt của cùng một đồng tiền" . Nói tóm lại, nó tuyên bố rằng về mặt toán học, cả hai cách tiếp cận đều dựa trên cùng một lý thuyết, nhưng với một số khác biệt.

Theo ý kiến ​​của tôi, có một số khác biệt thú vị: hướng của các phụ thuộc kiểu chéo (FK trong SQL) trái ngược với SQL và NoQuery và loại bộ sưu tập không bị giới hạn để đặt trong NoQuery (và do đó một số hoạt động theo lý thuyết tập hợp có thể không áp dụng trong thế giới NoQuery nữa, nhưng một số người khác vẫn còn hiệu lực). Một điểm thú vị khác từ bài viết là ngôn ngữ truy vấn duy nhất được đề xuất để truy vấn cả cơ sở dữ liệu SQL và NoQuery. Nó được gọi là LINQ và nếu bạn nghĩ rằng bạn có thể đã nghe thấy tên này trước đây, thì bạn đã đúng: đó là ngôn ngữ truy vấn của Microsoft từ C #.

Câu trả lời của Snowman mô tả chính xác cách SQL và NoQuery khác nhau trong cấu trúc dữ liệu của họ và cách chúng được truy cập. Tuy nhiên, một sự khác biệt thậm chí quan trọng hơn là miền vấn đề tương ứng của họ.

NoQuery không phải là sự kế thừa của SQL. Thay vào đó, các nhánh khác nhau của NoQuery hy sinh một số phẩm chất của SQL để có thể tốt hơn những người khác . Định lý CAP nói rằng không thể có bất kỳ hệ thống cơ sở dữ liệu phân tán nào thỏa mãn tất cả các thuộc tính sau:

• Tính nhất quán
• khả dụng
• Dung sai phân vùng

Do đó, một số biến thể NoQuery tuân theo nguyên tắc BASE thay vào đó, giúp nới lỏng ràng buộc luôn luôn đầy đủ của ACID , là cơ sở cho các cơ sở dữ liệu SQL cổ điển. Bằng cách mất một số đảm bảo tính nhất quán, họ có được khả năng kết hợp tính sẵn sàng cao và dung sai phân vùng trong các hệ thống phân tán rộng rãi, chẳng hạn như đối với các trang web có lượng dữ liệu và truy vấn người dùng cao, nhưng ít có nhu cầu về tính nhất quán hoàn hảo. Do đó, các cơ sở dữ liệu NoQuery như vậy là trung tâm của Google , Facebook và Amazon . Vì vậy, để trả lời câu hỏi của bạn: Có, NoQuery đột phá ở chỗ nó cho phép khá nhiều dịch vụ web lớn như vậy.

Đây chỉ là một ví dụ, vì NoQuery là một lĩnh vực đa dạng và các biến thể của nó bao gồm khá nhiều sự kết hợp các tham số có thể có trong tam giác CAP .

Các trường hợp sử dụng phổ biến của NoQuery là đột phá về mức tăng năng suất so với các cơ sở dữ liệu dựa trên SQL thông thường. Có một số yếu tố trong việc này.

Một là dọn phòng. Hầu hết các NoQuery là mã nguồn mở và có thể được cài đặt trên máy trạm hoặc máy ảo với một vài lệnh và hoạt động với các giá trị mặc định hợp lý. Theo kinh nghiệm của tôi, ngay cả Postgres và MySQL cũng không như vậy; cấu hình thường là cần thiết để bắt đầu ngay cả trên máy trạm cho mục đích phát triển.

Một cách khác là phát triển thuận tiện, như các câu trả lời khác đã mô tả chi tiết. Các khả năng lập chỉ mục JSON của Mongo, hoặc ngữ nghĩa khóa / giá trị của redis và Riak, có thể là tất cả các ứng dụng web nhất định cần để hoàn thành công việc và API rất dễ dàng. Một số NoQuery cung cấp API RESTful của riêng họ, trong khi với SQL, bạn thường phải tự viết chúng.

Những yếu tố này làm cho cơ sở dữ liệu NoQuery hấp dẫn cho các dự án quy mô nhỏ. Thời gian đón có xu hướng thấp. Chắc chắn, khi bạn đi vào sản xuất, bạn phải cấu hình để bảo mật và quy mô, nhưng khả năng bắt đầu mã hóa và cộng tác nhanh chóng là mạnh mẽ và, tôi lập luận, đột phá.

Ngoài ra, liên quan đến vấn đề trên, đối với các ứng dụng quy mô nhỏ (như dịch vụ nội bộ công ty hoặc ứng dụng đến ứng dụng), một nhóm có thể đứng lên cơ sở dữ liệu NoQuery sản xuất mà không liên quan đến các nhóm DBA của họ và không phải chịu hiệu suất hoặc tính toàn vẹn vấn đề là kết quả. Các DBA chuyên nghiệp có thể không thích điều này, nhưng các nhà phát triển coi DBA là nguồn gây cản trở (đúng hoặc sai) đôi khi xem NoQuery là một cách để vượt qua việc phải đối phó với chúng. Tôi thú nhận điều này - Tôi đã từng thay đổi một ứng dụng quy mô nhỏ từ Postgres sang SQLite để loại bỏ DBA đối nghịch và tôi đã chọn triển khai trên Mongo thay vì Oracle để tránh các quy trình phê duyệt DBA và hạn chế truy cập. Không có hậu quả bất lợi trong cả hai trường hợp.