Tôi đã chọc vào cơ sở dữ liệu AdventureWorks hôm nay và tôi nhận thấy rằng một số bảng ( HumanResources.JobCandidatevà Sales.Individualví dụ) có một cột lưu trữ dữ liệu xml.
Những gì tôi muốn biết là, lợi thế của việc lưu trữ dữ liệu về giá trị dữ liệu của một hàng của bảng cơ sở dữ liệu trong cột của bảng khác là gì? Điều này có gây khó khăn cho việc truy vấn thông tin này không? Hoặc giả định rằng dữ liệu sẽ không cần phải được truy vấn và chỉ cần được lưu trữ?
Câu trả lời:
Bởi vì không phải tất cả dữ liệu cần được lưu trữ một cách tương đối và viết mã để xử lý dữ liệu bạn đã được chuyển qua dưới dạng XML để lưu trữ quan hệ là tốn thời gian (và rất rất tẻ nhạt). Điều này đặc biệt đúng khi có rất nhiều dữ liệu XML đến từ các hệ thống đang đưa ra các phản hồi chung lớn.
Tôi thường thấy các tình huống nhận được tin nhắn từ một hệ thống khác và chúng tôi không quan tâm đến 98% nội dung của nó. Vì vậy, chúng tôi phân tích nó để phân chia 2% mà chúng tôi quan tâm, lưu trữ liên quan và sau đó lưu trữ toàn bộ thư trong trường hợp chúng tôi cần bất kỳ 98% còn lại nào sau đó.
Và SQL Server cung cấp cho bạn một số công cụ và cú pháp OK để làm việc với XML trong T-SQL, do đó, nó hoàn toàn không vượt quá khả năng thực tế đối với các truy vấn đặc biệt theo cách mà bạn có thể lưu trữ, giả sử, nội dung của một CSV.
Và điều đó loại trừ khả năng những gì bạn thực sự muốn lưu trữ là XML (ví dụ cho mục đích hỗ trợ và gỡ lỗi) ...
Nếu định dạng dữ liệu không ổn định và có thể thay đổi, bạn có thể đặt nó dưới dạng XML và đưa vào cơ sở dữ liệu ở dạng này để tránh thay đổi lược đồ cơ sở dữ liệu trong tương lai.
Trên cùng một tiếp tuyến, nếu dữ liệu được cung cấp bởi một số hệ thống bên ngoài và được sử dụng lại bởi nó và họ không thể cung cấp cho bạn một định dạng cố định, đó là những gì bạn sẽ làm.
Điều này có gây khó khăn cho việc truy vấn thông tin này không?
SQL Server có thể truy vấn các trường và biến XML. Không hẳn là khó khăn, nhưng công việc nhiều hơn, vâng. Nhưng có thể làm được.
Theo kinh nghiệm của tôi, dữ liệu XML thường được lưu trữ và hiếm khi được truy vấn, nhưng thường được trích xuất khi cần thiết, thường là khi một số hệ thống khác cần biểu diễn XML của một số dữ liệu có thể khó hoặc không thể tạo ra nhanh chóng từ dữ liệu quan hệ. Dữ liệu XML có thể được điền trước bởi một số quy trình khác.
Nếu bạn có thể tưởng tượng việc lưu trữ dữ liệu của mình trong luồng nhị phân trong một blob, thì tôi sẽ tưởng tượng bạn có thể tưởng tượng việc lưu trữ dữ liệu của bạn ở định dạng xml trong một blob.
Tất nhiên, nhiều thứ còn lại tốt nhất trong trí tưởng tượng của người tưởng tượng.
Nói, hồ sơ y tế điện tử chẳng hạn:
Vì rất có thể bạn sẽ lưu trữ ASCII HL7 V2.x trong một trường trong cơ sở dữ liệu. Bạn có thể có khả năng lưu trữ HL7 V3.0 trong một trường trong cơ sở dữ liệu.
Vì vậy, lợi thế là sự tiện lợi.
Tôi hiện đang làm việc trên một dự án làm điều này. Chúng tôi có dữ liệu cần được xử lý nhiều lần, được lưu trữ liên quan. Tuy nhiên, việc xử lý được thực hiện bằng Java và làm việc với XML ở đó dễ dàng hơn. Vì vậy, chúng tôi thực hiện một lần thông qua dữ liệu quan hệ và lưu trữ dưới dạng XML trong một bảng. Sau đó, chúng ta có thể xử lý dữ liệu đó trong Java bằng một truy vấn không tham gia thay vì truy xuất dữ liệu mỗi lần và xử lý cùng một dữ liệu theo nội dung trái tim của chúng ta. Nó đơn giản hơn nhiều và hiệu quả hơn.
Một ví dụ điển hình về việc lưu trữ XML là khi bạn muốn duy trì trạng thái UI trong cơ sở dữ liệu. Trạng thái của tất cả các khung nhìn ứng dụng được tuần tự hóa và được lưu trữ trong cơ sở dữ liệu và không cần phải truy vấn XML. Theo trạng thái UI, ý tôi là sắp xếp thứ tự xem, kích thước của các cửa sổ, v.v.
Thường thì bạn nhận được dữ liệu hỗn hợp cả XML và quan hệ. (Một ví dụ điển hình của việc này là một kho lưu trữ tài liệu trong đó mỗi tài liệu có thể có các trường siêu dữ liệu như tiêu đề, ngày tạo, chủ sở hữu, v.v.)
Tại thời điểm này, bạn phải chọn từ ba tùy chọn:
Tùy chọn 3 có lẽ là sạch nhất nhưng cũng đắt nhất và khó thực hiện nhất, cộng với bạn không nhất thiết muốn giao dịch phân tán trong một hệ thống không quá lớn. Tùy chọn 2 không tốt lắm vì cơ sở dữ liệu XML nguyên gốc thường rất kém trong việc xử lý dữ liệu quan hệ (mà bạn có khả năng sử dụng nhiều hơn trong các tìm kiếm) và công nghệ nói chung kém trưởng thành hơn DB quan hệ.
Vì vậy, điều đó khiến bạn có lựa chọn 1 vì chắc chắn không phải là giải pháp tốt nhất nhưng có thể là kém nhất.
Theo kinh nghiệm của tôi, việc sử dụng XML trong cơ sở dữ liệu kết thúc là vì đó là cách nguồn dữ liệu lưu trữ hoặc bạn thêm nó vào cơ sở dữ liệu hiện có để mở rộng chức năng theo cách không yêu cầu nhiều lập trình cơ sở dữ liệu để hỗ trợ .
Nếu bạn thường xuyên tìm kiếm dữ liệu mới, có thể nên tách XML thành các phần thành phần thay thế. Nếu không, nó có thể là một cách hữu ích để lưu dữ liệu thay đổi không thường xuyên.
Hy vọng điều này sẽ giúp, Jeff
Những kho dữ liệu hướng tài liệu (hay còn gọi là NoSql) rất phổ biến hiện nay:
http://en.wikipedia.org/wiki/Document-oriented_database
Không có lý do gì bạn không thể sử dụng sơ đồ hướng tài liệu trong cơ sở dữ liệu quan hệ. Bạn có thể không nhận được tất cả các lợi ích tương tự so với những thứ như Mongo, nhưng bạn cũng sẽ không có nhược điểm.
Trong một thời gian dài, nếu bạn muốn sử dụng lưu trữ hướng tài liệu, lựa chọn duy nhất của bạn là đẩy dữ liệu có cấu trúc (như XML) vào một cột lớn. Các cơ sở dữ liệu quan hệ đã được thêm các tính năng như lập chỉ mục và kết hợp để hỗ trợ điều đó.
Trái ngược với Mongo, nơi họ chỉ có một thứ trong cơ sở dữ liệu là tài liệu. Nhưng đó là một chủ đề khác.
EDIT: ý tưởng cốt lõi của định hướng tài liệu là: bạn kéo dữ liệu ra, thao tác với nó và đẩy toàn bộ dữ liệu trở lại. Đôi khi, giống như khi bạn truyền tài liệu đến máy khách, bạn chỉ muốn gửi toàn bộ nội dung dưới dạng blob và để họ giải quyết. Lợi ích (và nhược điểm) là tính linh hoạt. Xác nhận và tính chính xác của tài liệu được thực hiện bên ngoài cơ sở dữ liệu.
EDIT EDIT: Một sự tương phản khác. Hãy tưởng tượng lưu hình ảnh JPG hoặc tài liệu Word trong cột cơ sở dữ liệu.
Những lợi thế của việc lưu trữ một cây (XML) trong danh sách các bộ dữ liệu (bảng cơ sở dữ liệu) là gì?
Không có lý do tại sao XML không nên truy vấn được từ DBMS của bạn bằng cách sử dụng ví dụ XPath hoặc SPARQL.
Như tôi thấy, chúng chỉ đơn giản là hai cấu trúc dữ liệu khác nhau. Và không có lý do tại sao chúng không nên được nhúng vào nhau.
Bạn có thể tra cứu các lý do tại sao kiểu dữ liệu JSON được thêm vào trong PostgreSQL. Tôi nghĩ rằng nhiều lý lẽ tương tự được áp dụng. Ngoại trừ điều đó với XML / XSD, thậm chí có thể xác thực nhiều hơn.
Chà, XML (hoặc JSON) là khá tốt để lưu trữ các metadatas với hệ thống phân cấp. Các lựa chọn thay thế là gì? Một bảng siêu dữ liệu với refid / key / value / height có thể? Nó hơi cồng kềnh (nhưng có lẽ tốt hơn để truy vấn nếu bạn cần làm điều đó). Lưu trữ một số dữ liệu xml về tài liệu (một hàng trong bảng tài liệu) khá thuận tiện khi bạn muốn lưu trữ một số thông tin phân cấp mà không phải dựa vào bảng bên ngoài hoặc phải thêm 1 cột cho mỗi "loại" thông tin.
Tôi muốn nói rằng đó là một thực tế tồi tệ khi bạn làm tắc nghẽn lưu trữ hiệu quả với các thẻ không hiệu quả mà không cần phải có nếu bạn nỗ lực phân tích thông tin. XML có một chi phí lưu trữ gớm ghiếc so với dữ liệu mà nó mô tả, vì bạn cần một thẻ cho mỗi cột cho mỗi hàng. Khi so sánh, dữ liệu được phân tích cú pháp và được lưu trữ ở định dạng quan hệ có tên cột được lưu trữ ONCE. Đối với một tá hàng trên một dev. hộp, vấn đề lớn, nhưng tôi đã thấy các nhà phát triển đưa ra giả định rằng điều này có thể mở rộng đến hàng triệu hàng. Điều này có thể đại diện cho 100 GB chi phí cho vài chục GB dữ liệu, điều này tạo ra những thách thức trong hoạt động. Về cơ bản, bạn đang thoái thác trách nhiệm từ chính mình và thúc đẩy những người phải hỗ trợ những thứ nhảm nhí mà bạn đã viết.
Vì vậy, tại sao không lưu trữ nó TUYỆT VỜI từ dữ liệu vận hành, trong cơ sở dữ liệu của chính nó? Hoặc như nó dự định - trong các tập tin phẳng? Có lẽ nó sẽ không bao giờ được nhìn lại nữa, vậy tại sao không loại bỏ nó khỏi việc đánh vào hiệu năng của một hệ điều hành? Hãy nhớ rằng XML chỉ có ở đó để cung cấp một mô tả về lược đồ dữ liệu mà nếu không thì sẽ không rõ ràng do sự khác biệt về giao thức lưu trữ giữa các hệ thống. Đó là toàn bộ quan điểm của nó, không có gì thông minh về nó. Lưu trữ gấp 10 lần tổng chi phí cho một lượng dữ liệu nhất định chỉ nói rằng bạn là nhà phát triển cẩu thả, người không nghĩ đến mọi thứ và không thể xử lý dữ liệu bạn đang sử dụng thành định dạng truy vấn nhanh, hiệu quả, nhanh chóng. Ngừng nỗ lực của bạn lên hỗ trợ vận hành và NGHINK về cách bạn có thể xử lý dữ liệu tốt hơn sau khi bạn ' đã nhận được nó sẽ là cuộc gọi của tôi. Không có biện pháp bảo vệ dữ liệu dưới dạng XML sau khi nhận được, vì nó phục vụ mục đích của nó.