Khi nào tôi nên sử dụng kiểu dữ liệu XML trong SQL Server?

Khi nào tôi nên sử dụng kiểu dữ liệu XML trong Microsoft SQL Server?

Tôi đã thực hiện một điều tương tự khi tôi tuần tự hóa dữ liệu đối tượng thành XML để lưu trữ. Điều này loại bỏ gánh nặng của việc có các bảng, cột và các mối quan hệ tại chỗ để giữ dữ liệu cho các đối tượng phức tạp. Quá trình có thể được trợ giúp bằng cách sử dụng một lược đồ mà XML kết quả phù hợp và các bảng cơ sở dữ liệu có thể được sử dụng cho thông tin meta về các đối tượng được đề cập. Trong trường hợp của tôi, mở rộng lược đồ cơ sở dữ liệu để phù hợp với bố cục đối tượng sẽ là một nhiệm vụ lớn!

Cá nhân tôi chưa bao giờ sử dụng loại trường XML trong SQL Server và tôi đã thực hiện nhiều chương trình cơ sở dữ liệu kể từ khi họ thêm tính năng này. Dường như luôn có một chương trình và hiệu suất hoạt động để sử dụng nội dung XML trong cơ sở dữ liệu nguyên bản. Tôi thành thật nghĩ rằng đó là một mánh lới quảng cáo, bởi vì mọi người đều ở trên tàu XML tại một thời điểm vào đầu những năm 2000. "Oh XML rất hấp dẫn, vì vậy, hãy thêm nó vào SQL Server để chúng tôi không nhìn vào."

Trường hợp kinh doanh tốt nhất tôi có thể thấy có thể là trong việc ghi lại các thông điệp dữ liệu dựa trên XML mà bạn đã nhận được ở nơi bạn có thể muốn xem qua cấu trúc và dữ liệu của chúng, nhưng muốn duy trì tính toàn vẹn của thông điệp gốc vì lý do kinh doanh hoặc pháp lý. Chi phí hoạt động có thể quá lớn để dịch XML thành cấu trúc bảng, nhưng sử dụng các khả năng XML trong SQL Server có thể giúp giảm chi phí kiểm tra dữ liệu đủ để đảm bảo sử dụng nó.

Có thể có hàng tá lý do khác khiến bạn muốn sử dụng nó, nhưng thật lòng tôi nghĩ bạn nên xem xét các con đường khác để hạnh phúc trước khi phát triển nhanh với XML trong SQL Server trừ khi bạn có lý do kinh doanh rất cụ thể để làm như vậy. Sử dụng một varchar (max) hoặc trường văn bản nếu nó có ý nghĩa hơn.

Hiển nhiên đó chỉ là ý kiến ​​của tôi thôi :)

Tôi chỉ gặp một vài tình huống trong đó tôi sẽ chủ động theo đuổi việc sử dụng kiểu dữ liệu XML trong SQL Server. Đây là trên đỉnh đầu của tôi, theo thứ tự từ ít nhất đến thú vị nhất:

• Lưu trữ / lưu trữ các phản hồi XML được tạo bởi các ứng dụng khác
  • Ví dụ: chúng tôi sử dụng Khung tích hợp ứng dụng (AIF) để liên lạc giữa ứng dụng Silverlight tùy chỉnh và Dynamics AX. Chúng tôi lưu trữ cả tin nhắn gửi đến và gửi đi trong cơ sở dữ liệu để hỗ trợ khắc phục sự cố liên lạc giữa các ứng dụng đó
  • Vì loại trường là XML chứ không phải là loại chuỗi chung (ví dụ VARCHAR), chúng tôi có thể sử dụng XQuery để truy vấn cụ thể các thông báo phù hợp với một số tiêu chí cụ thể. Điều này sẽ khó khăn hơn nhiều với kết hợp chuỗi đơn giản THÍCH
• Bộ nhớ đệm / duy trì một tin nhắn phản hồi tổng hợp
  • Cập nhật trường XML bằng mã kích hoạt hoặc mã ứng dụng, sẽ bắt chước một cột được tính toán
  • Thay vì liên tục tạo lại phản hồi XML cho ứng dụng gọi điện, bạn sẽ chỉ phải chịu chi phí khi hàng được tăng, thay vì trên mỗi cuộc gọi
  • Điều này hoạt động tốt nhất khi các CHỌN thường xuyên hơn nhiều so với CẬP NHẬT / CHERTN, điều này có xu hướng đúng với hầu hết các ứng dụng
• Lưu trữ nhiều giá trị trong một trường
  • Một trong những thực tiễn tôi đã thấy là sử dụng loại dữ liệu XML để lưu trữ một tập hợp các giá trị trong một trường duy nhất
  • Một lợi ích là bạn không cần thiết kế thêm một bộ bảng cho kho lưu trữ khóa / giá trị đơn giản
  • Một nhược điểm của điều này là dữ liệu không được chuẩn hóa hoàn toàn, khiến việc truy vấn trở nên ít rõ ràng hơn
  • Tuy nhiên, như đã đề cập ở trên, bạn có thể sử dụng XQuery trên trường XML đó để chọn các hàng khớp với các tiêu chí xác định, do đó làm giảm bớt một phần tác động của việc không được chuẩn hóa hoàn toàn.

Tất cả những gì đã nói, 99% thời gian, tôi hoàn toàn không cần trường XML khi thiết kế lược đồ.

Một vài lần tôi đã thấy kiểu dữ liệu XML trong máy chủ SQL, về cơ bản nó được sử dụng như một trường đã được truy vấn giống như bất kỳ cơ sở dữ liệu nào khác, có thể có một số hàm ý hiệu suất rất tệ nếu bạn có một lượng dữ liệu lớn . Có một lý do nó được gọi là máy chủ SQL chứ không phải máy chủ XML. :-) Các truy vấn đi ngược lại với XML đơn giản là không nhanh bằng truy vấn chọn thông thường.

Tôi có thể thấy nó đang được sử dụng để lưu trữ XML mà không được yêu cầu nhiều như vậy, giả sử lưu trữ tài liệu XML đầy đủ trong một loại dữ liệu XML, nhưng có các trường (khóa) có thể tìm kiếm được lưu trữ riêng với tài liệu XML. Bằng cách đó, bạn có thể truy vấn thông tin của mình nhanh hơn và kéo tài liệu XML lên khi bạn đến điểm mà bạn muốn xem tài liệu đầy đủ. Tôi thực sự đã phải quay lại và làm điều này với một số ứng dụng mà mọi người đã cố gắng sử dụng kiểu dữ liệu XML như một trường được yêu cầu nhiều và dữ liệu đã phát triển đến mức truy vấn trở nên quá chậm.

Tôi đã sử dụng các trường loại XML chủ yếu cho các mục đích ghi nhật ký liên quan đến dịch vụ web ASMX hoặc dịch vụ WCF. Bạn có thể lưu yêu cầu hoặc tin nhắn phản hồi.

Hầu hết, bạn lưu XML trong DB cho mục đích tham khảo - không dành cho hoạt động kinh doanh thông thường của bạn (không truy vấn nó cứ sau 5 giây từ mã). Nếu bạn thấy mình làm như vậy, hãy xác định các trường mà bạn thường truy vấn hoặc sử dụng hầu hết thời gian và tạo các cột riêng cho chúng. Theo cách đó, khi bạn lưu XML vào DB, bạn có thể trích xuất các trường này và lưu chúng vào các cột tương ứng của chúng. Sau này trong khi truy xuất chúng, bạn sẽ không cần truy vấn tài liệu XML, bạn chỉ có thể sử dụng các cột bạn đã tạo cho mục đích này.

Đây là những tình huống xuất hiện trong đầu bất chợt khi xem xét những điều kiện cần tồn tại để cho phép các trường Xml trong Sql Server:

• dữ liệu nhị phân được mã hóa để trao đổi nơi bạn muốn axit như kiểm soát tài nguyên
• các đoạn tài liệu sẽ được hoàn nguyên trong toàn bộ bằng cách sử dụng thông tin động
• người dùng đã gửi tài liệu hoặc đoạn mà bạn muốn cô lập và ít nhất là trên cơ sở tạm thời, hãy tắt hệ thống tệp trực tiếp.

Tôi sử dụng XML rộng rãi trong các ứng dụng máy chủ-máy khách để lưu dữ liệu có cấu trúc trong một cuộc gọi đến cơ sở dữ liệu. Như một ví dụ, hãy lấy Hóa đơn với các dòng Chi tiết. Thật đơn giản để khách hàng tuần tự hóa đối tượng kinh doanh thành XML và chuyển đến một Proc được lưu trữ trong một cuộc gọi. Proc quyết định xem có cần chèn hay cập nhật hay không; nó có thể lấy ID hóa đơn gốc (một cột danh tính) để gán cho các bản ghi chi tiết, tất cả trong một giao dịch phía máy chủ và không có khách hàng phải thực hiện nhiều chuyến đi khứ hồi. Tôi không cần 20 tham số để chỉ định bản ghi tiêu đề và tôi không phải thực hiện cuộc gọi cho mỗi dòng hóa đơn. Ngoài ra, thường có thể thực hiện thay đổi lược đồ hoặc giới thiệu ghi nhật ký / kiểm toán mà không cần phải chạm vào máy khách.