IBM pureXML, một cơ sở dữ liệu XML độc quyền được xây dựng trên cơ chế quan hệ (được thiết kế để chơi chữ) cung cấp cả ngôn ngữ truy vấn quan hệ (SQL / XML) và không có cấu trúc (XQuery) và MarkLogic, một cơ sở dữ liệu được xây dựng từ dựa trên mô hình cơ sở dữ liệu mới (gọi nó là NoSQL nếu bạn muốn) hiểu dữ liệu phi cấu trúc và cung cấp ngôn ngữ truy vấn phi cấu trúc (XQuery).
Một thông tin quan trọng khác là xu hướng mới giữa các nhà cung cấp cơ sở dữ liệu NoSQL để triển khai SQL (hoặc giao diện giống SQL). Một ví dụ là quảng cáo gần đây của Cassandra với CQL hoặc các giao diện SQL hoàn thiện hơn dựa trên Hadoop.
Khi hai thế giới va chạm
NoSQL về Không có SQL. Đối với tôi, điều này có nghĩa là chuyển trọng tâm sang các lựa chọn thay thế cơ sở dữ liệu không quan hệ, thậm chí có thể khám phá các giao diện khác nhau đối với cơ sở dữ liệu (và không quan tâm đến tính đúng đắn chính trị). Đây là một điều tốt! Thừa nhận điểm yếu của SQL cho doanh nghiệp một cách mù quáng? Chà, ngay cả khi SQL là lựa chọn phù hợp cho sản phẩm của bạn, bạn vẫn phải nghĩ đến hậu quả và đảm bảo rằng mọi thứ được liên kết tốt giữa hai thế giới. Nói cách khác, điều đó có nghĩa là loại bỏ phần "mù" và giảm "khập khiễng" xuống mức tối thiểu có thể chấp nhận được đối với các nhà phát triển của bạn.
Mô hình dữ liệu
Trong mối quan hệ bạn có:
RowSet -> SQL -> RowSet
RowSet là một cái gì đó giống như vậy:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Tôi sẽ cho bạn biết về mô hình dữ liệu XPath:
XDM -> XPath/XQuery -> XDM
Và XDM là một cái gì đó như thế:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Cả hai đều được đơn giản hóa, nhưng phục vụ một mục đích).
Một đặc điểm khác biệt của mô hình dữ liệu cho tài liệu là các cây không bằng phẳng:
{
"namespace": "person-2.0",
"comments": "This guy asked me for a dinosaur sticker. What a nutter!",
"person": {
"handle": "dscape",
"comments": "Please do not send unsolicited mail."
}
}
Do đó, có nhiều cách hiểu về ý nghĩa của điều này:
SELECT comments from PERSON where handle = "dscape"
Yêu cầu đề cập đến yếu tố nào của “nhận xét”? Nếu bạn nhìn vào SQL / XML, truy vấn của bạn sẽ giống như sau:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Điều này dẫn đến kết luận hiển nhiên:cây cối cần có cách để định hướng. Trong XML, nó là XPath, trong JSON, nó có thể là JSONSelect, có thể là một cái gì đó khác. Nhưng bạn vẫn cần phương pháp điều hướng tiêu chuẩn ngay từ đầu.
Điều làm cho nhiệm vụ này thú vị hơn nữa là kiểm soát phiên bản và phát triển mạch. Mặc dù thực tế là điều này đã bị bỏ qua trong nhiều thời kỳ trong thế giới quan hệ (với hậu quả nghiêm trọng đối với công việc kinh doanh do thời gian ngừng hoạt động trong những khoảnh khắc thay đổi bảng vui nhộn này). , điều này quả thực không thể bỏ qua đối với tài liệu. Hãy nghĩ về Microsoft Word - chúng hỗ trợ bao nhiêu phiên bản tài liệu khác nhau? Word 2003, 2005, v.v.
Không có lược đồ, tính linh hoạt, không có cấu trúc:hãy chọn từ của bạn, nhưng tất cả chúng đều phụ thuộc vào sự phát triển nhanh chóng của các định dạng dữ liệu. Trong truy vấn này, chúng tôi giả định rằng bộ mô tả là một đứa trẻ con người và những nhận xét rằng tôi là một tên ngốc là hậu duệ trực tiếp của cây. Điều này chắc chắn sẽ thay đổi. Và SQL không hỗ trợ lập phiên bản của tài liệu, vì vậy bạn sẽ phải mở rộng nó để làm cho nó hoạt động.
Ngôn ngữ truy vấn thực cho dữ liệu phi cấu trúc phải tính đến phiên bản. Trong XQuery, chúng ta có thể diễn đạt truy vấn này như sau:
declare namespace p = "person-2.0" ;
for $person in collection('person')
let $comments-on-person := $person/p:comments
where $person/p:handle = "dscape"
return $comments-on-person
Frankenqueries chẳng hạn
Ai đó đã từng đề cập đến tôi (nói về SQL / XML) với cái tên Frankenqueries này. Thuật ngữ này đã bám chặt vào đầu tôi cho đến nay. Hãy xem xét xa hơn một chút về sự tương tự này và tìm kiếm những vị trí mà các bộ phận hữu cơ và bu lông kết hợp với nhau.
Hãy trình bày hai danh sách mua sắm, một cho Joe và một cho Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Bây giờ với tiện ích mở rộng SQL / JSON “tưởng tượng” của mình, tôi thực hiện:
SELECT apples
FROM LISTS
Nó trả lại cái gì? Hãy nhớ rằng RowSet tham gia, RowSet ra ngoài?
2, 5
---
6
Do đó, ngay cả khi bạn yêu cầu rõ ràng danh sách các số apple, bạn sẽ nhận được hai tập hợp hàng thay vì ba và một trong các tập hợp hàng sẽ có danh sách số. Nếu bạn chọn trả lại ba thứ thay vào đó, bạn sẽ nhận được hai bộ RowSet và ba bộ RowSet. Tôi không phải là nhà toán học, nhưng điều đó nghe có vẻ không ổn.
Một lần nữa, sẽ không thành vấn đề nếu bạn sử dụng thứ gì đó có thể xử lý thông tin không có cấu trúc. Bạn không gặp vấn đề này trong javascript và tất nhiên, nó sẽ không xảy ra trong XQuery. Cả trong javascript và XQuery, tất cả đều là hữu cơ.
Kết luận:ngôn ngữ tuyệt vời cho dữ liệu phi cấu trúc, kỳ lân và bụi pixie!
Mặc dù XQuery là một ngôn ngữ tuyệt vời cho thông tin phi cấu trúc, nhưng quan điểm của tôi ở đây không bảo vệ việc sử dụng nó. Điểm tôi đang cố gắng nhấn mạnh là nhu cầu về ngôn ngữ thực cho dữ liệu phi cấu trúc, bất kể bạn (đọc:nhà phát triển) chọn nó như thế nào.
Nhưng tôi yêu cầu bạn (các nhà phát triển) không lấy lại “SQL khập khiễng”. Cô ấy đi rồi và bạn có một cuộc hẹn hò nóng bỏng mới có tên là NoSQL. Chỉ cần cho nó một thời gian và nó sẽ phát triển trên bạn. Cũng rất thú vị khi viết mã JavaScript hoạt động trong cơ sở dữ liệu:đừng để chúng lấy đi của bạn.
SQL cho dữ liệu không có cấu trúc sẽ không thành công. Sau đó, PL-SQL cho dữ liệu phi cấu trúc sẽ không thành công. Vì vậy, nếu nhà cung cấp nhấn mạnh vào những gì bạn cần, đừng chấp nhận bất kỳ thứ gì ít hơn một ngôn ngữ lập trình đầy đủ:bạn có thể viết ứng dụng hoàn chỉnh của mình bằng javascript và lưu nó trong CouchApp hoặc bạn có thể viết ứng dụng hoàn chỉnh của mình trong XQuery và lưu nó trong MarkLogic . Và vì vậy nó nên như vậy!
Đây là danh sách kiểm tra những gì cần tìm trong ngôn ngữ truy vấn cho thông tin phi cấu trúc:
- Ngôn ngữ của điều hướng
- Mô hình dữ liệu
- Biểu thức bình thường
- Lambda
- Chức năng của thứ tự cao
- Hương thơm chức năng
- Xử lý dòng tốt
- Mô-đun để bạn có thể tạo thư viện của riêng mình
- Máy chủ ứng dụng được biết:có các chức năng phục vụ REST
Bạn có thể bỏ qua lời khuyên này, nhưng cuối cùng, bạn có thể cảm thấy thất vọng với nhà phát triển Silverlight. Và chúng tôi, những người thích đổi mới trong cơ sở dữ liệu, sẽ thất vọng khi các nhà phát triển quyết định quay trở lại!
