Kiedy powinienem używać typu danych XML w SQL Server?

Kiedy powinienem używać typu danych XML w Microsoft SQL Server?

Zrobiłem podobną rzecz, w której serializuję dane obiektów do XML w celu przechowywania. To usuwa ciężar posiadania tabel, kolumn i relacji w celu przechowywania danych dla złożonych obiektów. Procesowi można pomóc, korzystając ze schematu zgodnego z wynikowym kodem XML, a tabel bazy danych można użyć do uzyskania meta informacji o przedmiotowych obiektach. W moim przypadku rozbudowanie schematu bazy danych w celu dostosowania do układu obiektu byłoby dużym zadaniem!

Osobiście nigdy wcześniej nie używałem typu pola XML w SQL Server i dużo programowałem w bazie danych, ponieważ dodali tę funkcję. Zawsze wydawało mi się, że narzucanie natywnego wykorzystania treści XML w bazie danych wiąże się z nadmiernym obciążeniem programistycznym i wydajnościowym. Szczerze myślałem, że to sztuczka, ponieważ wszyscy byli w pociągu XML w pewnym momencie na początku 2000 roku. „Och, XML jest gorący, więc dodajmy go do SQL Server, abyśmy nie wyglądali na przechodzących”.

Najlepszym przykładem biznesowym, jaki widzę, może być rejestrowanie otrzymanych wiadomości opartych na XML, w których możesz zajrzeć do ich struktury i danych, ale chcesz zachować integralność oryginalnej wiadomości ze względów biznesowych lub prawnych. Narzut może być zbyt duży, aby przetłumaczyć XML na strukturę tabeli, ale użycie możliwości XML w SQL Server może po prostu obniżyć koszty badania danych na tyle, aby uzasadnić ich użycie.

Prawdopodobnie istnieją dziesiątki innych powodów, dla których warto z niego skorzystać, ale szczerze mówiąc, myślę, że powinieneś rozważyć inne ścieżki do szczęścia przed pójściem na całość z XML w SQL Server, chyba że masz bardzo konkretne biznesowe powody. Użyj varchar (maks.) Lub pola tekstowego, jeśli ma to większy sens.

Oczywiście tylko moja opinia :)

Zetknąłem się tylko z kilkoma scenariuszami, w których aktywnie kontynuowałbym użycie typu danych XML w SQL Server. To jest z góry mojej głowy, w kolejności od najmniej do najciekawszych:

• Przechowywanie / archiwizacja odpowiedzi XML generowanych przez inne aplikacje
  • Na przykład używamy Application Integration Framework (AIF) do komunikacji między niestandardową aplikacją Silverlight a Dynamics AX. W bazie danych przechowujemy zarówno wiadomości przychodzące, jak i wychodzące, aby pomóc w rozwiązywaniu problemów z komunikacją między tymi aplikacjami
  • Ponieważ typ pola to XML, a nie ogólny typ ciągu (tj. VARCHAR), możemy użyć XQuery do specyficznego zapytania o wiadomości spełniające określone kryteria. Byłoby to o wiele trudniejsze z prostym dopasowaniem typu LIKE
• Buforowanie / utrwalanie złożonego komunikatu odpowiedzi
  • Zaktualizuj pole XML kodem wyzwalacza lub aplikacji, który naśladowałby obliczoną kolumnę
  • Zamiast ciągłego ponownego generowania odpowiedzi XML dla aplikacji wywołującej, ponosisz koszty ogólne tylko wtedy, gdy wiersz jest wstawiony, a nie przy każdym wywołaniu
  • Działa to najlepiej, gdy SELECT są znacznie częstsze niż UPDATE / INSERTs, co jest prawdą w większości aplikacji
• Przechowywanie wielu wartości w jednym polu
  • Jedną z praktyk, które widziałem, jest użycie typu danych XML do przechowywania kolekcji wartości w jednym polu
  • Jedną z korzyści jest to, że nie trzeba projektować dodatkowego zestawu tabel dla prostego magazynu kluczy / wartości
  • Minusem tego jest to, że dane nie są w pełni znormalizowane, przez co zapytania są mniej oczywiste
  • Jednak, jak wspomniano powyżej, możesz użyć XQuery na tym polu XML, aby wybrać wiersze, które pasują do kryteriów identyfikacyjnych, tym samym częściowo niwelując wpływ braku pełnej normalizacji.

To powiedziawszy, 99% czasu, absolutnie nie potrzebuję pola XML podczas projektowania schematu.

Kilka razy, gdy widziałem typ danych XML na serwerze SQL, był on zasadniczo używany jako pole, które zostało zapytane, tak jak każde inne w bazie danych, co może mieć bardzo zły wpływ na wydajność, jeśli masz dużą ilość danych . Istnieje powód, który nazywa się SQL Server, a nie serwer XML. :-) Zapytania skierowane przeciwko XML po prostu nie są tak szybkie jak zwykłe wybieranie zapytań.

Widziałem, że jest używany do przechowywania XML, który nie jest tak bardzo pytany, powiedzmy, przechowywanie pełnego dokumentu XML w typie danych XML, ale posiadanie pól (kluczy) z możliwością przeszukiwania zapisanych osobno z dokumentem XML. W ten sposób możesz szybciej wyszukiwać informacje i wyciągać dokument XML, gdy dojdziesz do punktu, w którym chcesz zobaczyć pełny dokument. W rzeczywistości musiałem wrócić i zrobić to z wieloma aplikacjami, w których ludzie próbowali użyć typu danych XML jako silnie wyszukiwanego pola, a dane wzrosły do ​​tego stopnia, że ​​zapytanie stało się zbyt wolne.

Użyłem pól typu XML głównie do celów logowania związanych z usługami sieciowymi ASMX lub usługami WCF. Możesz zapisać żądanie lub wiadomość z odpowiedzią.

W większości przypadków zapisujesz XML w bazie danych w celach referencyjnych - nie do zwykłej działalności biznesowej (nie pytaj go co 5 sekund z kodu). Jeśli to robisz, określ pola, które zwykle przeszukujesz lub których używasz przez większość czasu, i utwórz dla nich osobne kolumny. W ten sposób, kiedy zapisujesz XML w DB, możesz wyodrębnić te pola i zapisać je w odpowiadających im kolumnach. Później przy ich pobieraniu nie będziesz potrzebować przeszukiwać dokumentu XML, możesz po prostu użyć utworzonych w tym celu kolumn.

Oto scenariusze, które przychodzą mi do głowy od razu, gdy rozważamy, jakie warunki muszą istnieć, aby zezwolić na pola Xml w Sql Server:

• dane binarne kodowane do wymiany, w której chcesz kontrolować kwas jak kontrola zasobu
• fragmenty dokumentów, które zostaną odtworzone w całości z wykorzystaniem informacji dynamicznych
• użytkownik przesłał dokumenty lub fragmenty, które chcesz wyodrębnić i przynajmniej tymczasowo trzymać system plików bezpośrednio.

Używam XML w aplikacjach klient-serwer do zapisywania danych strukturalnych w jednym wywołaniu bazy danych. Jako przykład weźmy fakturę z wierszami szczegółów. Po prostu klient może serializować obiekt biznesowy do formatu XML i przekazywać do przechowywanego proc w jednym wywołaniu. Proc decyduje, czy wymagana jest wstawka czy aktualizacja; może uzyskać identyfikator faktury nadrzędnej (kolumnę tożsamości), aby przypisać go do rekordów szczegółowych, wszystko w ramach transakcji po stronie serwera i bez konieczności dokonywania przez klienta kilku podróży w obie strony. Nie potrzebuję około 20 parametrów, aby określić rekord nagłówka i nie muszę nawiązywać połączeń dla każdej linii faktury. Ponadto często można wprowadzać zmiany w schemacie lub wprowadzać rejestrowanie / inspekcję bez konieczności dotykania klienta.