RDBMS hiện đại có hỗ trợ cho các loại cột XML và chức năng để xử lý XML trong các thủ tục được lưu trữ. Trong lịch sử, tôi sẽ luôn luôn có ánh xạ dữ liệu phân cấp (cho dù các đối tượng OO hoặc XML) đến các bảng quan hệ. Với sự hỗ trợ cơ sở dữ liệu phổ biến cho XML nên tôi thay đổi cách của tôi?Tại sao tôi lại chọn lưu trữ và thao tác XML trong cơ sở dữ liệu quan hệ?
Bạn có thể lưu trữ XML do người dùng tạo trong đó.
Nếu một trang web như stackoverflow sử dụng một số loại đánh dấu XML thay vì đánh dấu xuống, bạn có thể lưu trữ các câu hỏi/câu trả lời dưới dạng XML trong cơ sở dữ liệu. Bạn có thể thấy mình đang phân tích cú pháp XML do người dùng tạo ra này đang tìm kiếm các thẻ độc quyền.
Giả sử bạn có một thực thể có thuộc tính. Bạn có thể lưu trữ tất cả các thuộc tính đó trong XML thay vì tạo một bảng thuộc tính riêng biệt. XML sẽ linh hoạt hơn.
Nếu bạn không thấy nhu cầu thì đừng thay đổi!
Đôi khi bạn phải duy trì dữ liệu không có cấu trúc đã biết hoặc cấu trúc của nó rất dễ bay hơi. Trong những trường hợp đó, thay vì tạo bảng, chỉ cần lưu XML vào bảng hiện tại của bạn
Nếu XML của nó mặc dù, bạn sẽ không mong đợi nó có một cấu trúc cố định hoặc ít nhất được xác định rõ? –
Không có X trong XML là gì? Nếu bạn muốn cố định, bạn chỉ cần sử dụng một tập hợp các bảng và các trường. Định nghĩa tốt là tốt nhưng định nghĩa có thể thay đổi thường xuyên hơn bạn có thể đẩy các thay đổi lược đồ cơ sở dữ liệu qua. – AnthonyWJones
Tính linh hoạt là một trong những lý do.
Nếu cấu trúc dữ liệu của bạn có thể khác nhau, thì bạn vẫn có thể giữ một bảng RDBMS chung, cùng với các truy vấn, v.v ... gor sau nó với dữ liệu có cấu trúc hơi sai.
Nếu bạn cần thêm một trường tại một thời điểm nào đó, bạn có thể làm như vậy mà không thay đổi cấu trúc bảng RDMS của bạn và do đó không làm hỏng truy vấn của người khác.
Tôi không chắc nó đơn giản như thế nào. Nếu các truy vấn được viết để trích xuất XML thì việc thay đổi cấu trúc của nó vẫn có thể phá vỡ mã xử lý các kết quả. –
Bạn có thể xử lý dữ liệu XML trực tiếp trong máy chủ SQL. Ví dụ. bạn có thể áp dụng các biểu thức XPath và chỉ gửi bộ kết quả đã lọc tới máy khách. Các tính năng của máy chủ SQL có thể xây dựng dựa trên các khả năng xử lý XML sau này.
Các tính năng trên tồn tại từ MS SQL Server 2000 hoặc 2005.
Nhưng bạn sẽ chỉ xử lý XML trong máy chủ nếu bạn lo lắng về chi phí chuyển quá nhiều vào ứng dụng máy chủ/ứng dụng khách? – tpower
Tôi không có XP thực tế về nó. Tôi có thể khuyên bạn nên đo lường hoặc tìm dữ liệu về hiệu suất xử lý XML của máy chủ của bạn. Tôi đọc trong một cuốn sách MCTS mà bạn có thể sử dụng xử lý XML trong MSSQL và nó được khuyên dùng. Kiểm tra TechNet hoặc MSDN để biết thêm chi tiết. – artur02
Xử lý XPath trong SQL Server rất chậm. –
Ví dụ, bạn sẽ có được các tài liệu XML từ một số hệ thống khác, với cấu trúc rất giàu hay phức tạp mà bạn muốn để lưu trữ; nhưng bạn chỉ cần một vài truy vấn được xác định rõ ràng để truy xuất dữ liệu đó. Trong trường hợp đó, chỉ cần phân tích cú pháp dữ liệu bạn cần để tạo ra một số chỉ mục và lưu trữ toàn bộ cấu trúc XML trong một trường duy nhất.
Để làm điều đó bạn không cần hỗ trợ XML cụ thể nhiều trên công cụ DB, nhưng nó vẫn giúp giữ cho các truy vấn biểu cảm. Ngoài ra, tôi đoán rằng một số DMBS có hỗ trợ XML tốt có thể cho phép bạn lưu trữ tài liệu XML, có thể không chỉ rõ cách lập chỉ mục nó như thế nào. Bạn chỉ cần sử dụng XQuery và hy vọng nó bằng cách nào đó tối ưu hóa nhu cầu của bạn.
Tôi có một ví dụ thực tế tốt. Một trong những khách hàng của tôi nhận được một tập tin XML từ các nhà cung cấp của họ rất thường xuyên với một số dữ liệu quan trọng. Nó được lồng sâu. Họ cần phải so sánh nó với tệp XML trước đó để xem những gì đã thay đổi. Nếu không có hỗ trợ XML trong cơ sở dữ liệu, tôi đã phải xây dựng một công cụ lặp qua các nút XML và tìm kiếm các kết quả phù hợp trong các bảng của cơ sở dữ liệu quan hệ. Tôi có thể sử dụng một số công cụ so sánh XML-XML, nhưng một số kiểm tra liên quan đến một số dữ liệu khác không đến từ tệp XML và tôi cần phải kết hợp tất cả những thứ đó với nhau. Ok, tất cả điều này không phải là vấn đề lớn, nhưng vẫn - với các cơ sở dữ liệu XML, bạn có được chức năng đó.
Đây là ví dụ về thế giới thực từ một hệ thống tôi làm việc. Chúng tôi có một hệ thống cốt lõi và tạo mã khách hàng cụ thể trong java. Một lớp khác có thể được gọi tùy thuộc vào khách hàng nào đang giao dịch. Đôi khi, mã tùy chỉnh này cần lưu trữ thứ gì đó và chúng tôi đặt nó vào một cột XML trong bảng có liên quan. Điều này tiết kiệm cho chúng tôi từ mô hình hóa tất cả mọi thứ dưới ánh mặt trời. Thêm một khách hàng mới thường chỉ có nghĩa là viết và cài đặt mã java.
Nhược điểm là báo cáo, truy vấn và cập nhật khó khăn hơn trên cột XML. Không có các tính năng cơ sở dữ liệu tốt thông thường như ràng buộc kiểm tra, v.v.
Tôi không có nhu cầu lưu trữ XML cho đến nay, nhưng tôi thường sử dụng khả năng trả về XML từ một thủ tục lưu sẵn. Nó làm cho một số điều rất hữu ích - chủ yếu là báo cáo. Tôi có thể chạy SP để tạo báo cáo, gửi lại kết quả trong XML và sau đó sử dụng XSLT để hiển thị kết quả trên trang web rất dễ dàng.
Tôi đã làm điều này quá, nhưng nó quy mô nặng. Một số báo cáo chúng tôi đã chạy đến hàng nghìn hàng. XML tất cả đã có trong bộ nhớ cùng một lúc (đầu tiên trên DB, sau đó trên máy khách) vs một recordset được hấp thụ và tiêu thụ. –
Tôi sử dụng loại cột XML để lưu trữ bản sao của tất cả các thông điệp quan trọng về kinh doanh mà chúng tôi nhận được từ dịch vụ của bên thứ ba. Nó rất tiện dụng vì một vài lý do.
1) Trong trường hợp bị hỏng dữ liệu, chúng tôi có thể theo dõi lại để xem dữ liệu nào xuất hiện khi nào và ở định dạng nào.
2) Công việc phát triển tương lai trên hệ thống có thể dựa trên dữ liệu thực tế từ bảng đăng nhập - chỉ cần deserialise và sử dụng dữ liệu như thể nó đến từ một cuộc gọi đến dịch vụ 3p
3) Đảm bảo rằng những kẻ infrasructure đang bận phân bổ đĩa không gian cho máy chủ DB. ;)
điều này có vẻ là một trong những lý do tốt nhất để sử dụng nó. không có đảm bảo khi giao dịch với bên thứ ba. :-P – user420667
Lý do duy nhất tôi có thể sử dụng lại lần nữa là khi có khả năng mở rộng & linh hoạt.
Chi phí đầu vào của xml (xpath) và bảo trì (không gian tên) thực sự không đáng phải lo lắng nếu bạn có thể tránh được. Trước đây chúng tôi đã lưu trữ một lượng lớn dữ liệu trong xml và các hàm vô hướng được sử dụng để truy xuất nó, nhưng nó quá chậm và gây ra nhức đầu to lớn là cấu trúc xml hoặc thay đổi không gian tên.
Nhưng tính linh hoạt là tuyệt vời. Bạn có thể thêm thuộc tính mới bất cứ khi nào bạn muốn, bạn có thể có dữ liệu cụ thể của dự án/khách hàng/công việc trong đó không yêu cầu cột thích hợp. XML không phải ở trong một cấu trúc tĩnh - bạn chỉ cần một nhà máy có thể sinh ra các cá thể để xử lý các XML khác nhau (cần phải liên quan đến một dự án/khách hàng/công việc).
Khi thêm bảng mới vào hệ thống hiện có, đặc biệt là bảng có nhiều dữ liệu hiện có và không thể sửa đổi dễ dàng, tôi sẽ thêm cột XML. Trong tương lai nếu tôi cần phải thêm một cột khác vào bảng đó, tôi có thể đơn giản sử dụng cột XML thay vì bị thất vọng và phải làm nhiều việc.
Tóm lại, bạn không bắt đầu bằng cách đặt các thuộc tính thiết yếu trong XML. Nhưng bạn nên thêm XML khi bạn biết rằng bảng của bạn có thể cần phải được mở rộng, chính xác bởi vì nó cung cấp cho bạn tùy chọn mở rộng.
Bạn có thể xây dựng không? –
Bạn cũng có thể thực hiện với trường LONGVARCHAR. – Horcrux7
Nhưng bạn có thể đặt một ràng buộc vào một varchar để nói rằng nó phải là hợp lệ XML. – tpower