Grzebałem dzisiaj w bazie danych AdventureWorks i zauważyłem, że wiele tabel ( HumanResources.JobCandidatei Sales.Individualna przykład) ma kolumnę, w której przechowywane są dane XML.
Chciałbym wiedzieć, jaka jest zaleta przechowywania w zasadzie wartości danych wiersza tabeli bazy danych w kolumnie innej tabeli? Czy to nie utrudnia zapytania o te informacje? A może założenie, że dane nie będą musiały być wyszukiwane, a jedynie przechowywane?
Odpowiedzi:
Ponieważ nie wszystkie dane muszą być przechowywane relatywnie, a pisanie kodu do przetwarzania danych przekazanych jako XML do przechowywania relacyjnego jest czasochłonne (i bardzo bardzo uciążliwe). Jest to szczególnie prawdziwe, gdy wiele danych XML pochodzi z systemów, które generują duże ogólne odpowiedzi.
Często widziałem sytuacje, w których wiadomość jest odbierana z innego systemu i nie obchodzi nas około 98% jej zawartości. Analizujemy to, aby rozdzielić 2%, na których nam zależy, przechowywać to relacyjnie, a następnie przechowywać całą wiadomość na wypadek, gdybyśmy potrzebowali któregokolwiek z pozostałych 98% później.
A SQL Server zapewnia pewne OK-narzędzia i składnię do pracy z XML-em w T-SQL, więc nie jest tak, że jest to całkowicie poza praktycznym zasięgiem zapytań ad-hoc, tak jak by to było, gdybyś przechowywał, powiedzmy, zawartość CSV.
A to wyklucza możliwość, że tak naprawdę chcesz przechowywać XML (na przykład do celów wsparcia i debugowania) ...
Jeśli format danych jest niestabilny i może ulec zmianie, możesz połączyć go jako XML i umieścić w bazie danych w tej formie, aby uniknąć przyszłej zmiany schematu bazy danych.
Z tego samego powodu, jeśli dane są dostarczane przez jakiś system zewnętrzny i ponownie przez niego wykorzystywane, a nie są w stanie zapewnić stałego formatu, to właśnie byś zrobił.
Czy to nie utrudnia zapytania o te informacje?
SQL Server może wyszukiwać pola i zmienne XML. Niekoniecznie trudne, ale więcej pracy, tak. Ale wykonalne.
Z mojego doświadczenia wynika, że dane XML są zwykle przechowywane i rzadko wysyłane do nich kwerendy, ale często wyodrębniane w razie potrzeby, zwykle gdy inny system potrzebuje reprezentacji XML niektórych danych, które mogą być trudne lub niemożliwe do wygenerowania w locie z danych relacyjnych. Dane XML mogą być wstępnie wypełnione przez inny proces.
Jeśli możesz sobie wyobrazić przechowywanie danych w strumieniu binarnym w obiekcie blob, wyobrażam sobie, że możesz sobie wyobrazić przechowywanie danych w formacie xml w obiekcie blob.
Oczywiście wiele rzeczy najlepiej pozostawić wyobraźni wyobraźni.
Powiedzmy, że elektroniczna dokumentacja medyczna, na przykład:
Ponieważ najprawdopodobniej przechowujesz plik ASCII HL7 V2.x w polu w bazie danych. Prawdopodobnie będziesz w stanie przechowywać HL7 V3.0 w polu w bazie danych.
Zaletą jest więc wygoda.
Obecnie pracuję nad projektem, który to robi. Mamy dane, które muszą być przetwarzane wiele razy, przechowywane relacyjnie. Jednak przetwarzanie odbywa się w Javie i tam łatwiej jest pracować z XML. Tak więc, wykonujemy jednorazowe przejście przez dane relacyjne i przechowujemy je jako XML w tabeli. Następnie możemy przetwarzać te dane w Javie za pomocą jednego nie dołączającego zapytania, zamiast pobierać dane za każdym razem, i przetwarzać te same dane w sposób ciągły do zadowolenia naszego serca. Jest o wiele prostszy i bardziej wydajny.
Dobrym przykładem przechowywania XML jest sytuacja, gdy chcesz zachować stany interfejsu użytkownika w bazie danych. Stan wszystkich widoków aplikacji jest szeregowany i przechowywany w bazie danych i nie ma potrzeby sprawdzania kodu XML. Przez stan interfejsu mam na myśli porządek sortowania, rozmiar okien itp.
Często otrzymujesz mieszane dane, zarówno XML, jak i relacyjne. (Dobrym przykładem tego jest magazyn dokumentów, w którym każdy dokument może mieć pola metadanych, takie jak tytuł, data utworzenia, właściciel itd.)
W tym momencie musisz wybrać jedną z trzech opcji:
Opcja 3 jest prawdopodobnie najczystszym, ale także najdroższym i najtrudniejszym do wdrożenia, a ponadto niekoniecznie chcesz rozproszonych transakcji w niezbyt dużym systemie. Opcja 2 nie jest zbyt dobra, ponieważ natywne bazy danych XML są zwykle bardzo słabe w obsłudze danych relacyjnych (których częściej używasz podczas wyszukiwania), a technologia jest ogólnie mniej dojrzała niż relacyjna baza danych.
To pozostawia Ci opcję 1 jako z pewnością nie najlepsze rozwiązanie, ale być może najmniej złe.
Z mojego doświadczenia wynika, że używanie XML w bazie danych kończy się dlatego, że tak przechowuje go źródło danych, albo dodajesz go do istniejącej bazy danych, aby rozszerzyć funkcjonalność w sposób, który nie będzie wymagał dużo programowania bazy danych do obsługi .
Jeśli zamierzasz często szukać nowych danych, warto zamiast tego podzielić XML na części składowe. Jeśli nie, może to być przydatny sposób zapisywania rzadko zmienianych danych.
Mam nadzieję, że to pomaga, Jeff
Magazyny danych zorientowane na dokumenty (znane również jako NoSql) są obecnie bardzo popularne:
http://en.wikipedia.org/wiki/Document-oriented_database
Nie ma powodu, dla którego nie można zastosować schematu zorientowanego na dokumenty w relacyjnej bazie danych. Możesz nie uzyskać takich samych korzyści w porównaniu z czymś takim jak Mongo, ale nie będziesz miał też wad.
Przez długi czas, jeśli chcesz używać pamięci zorientowanej na dokumenty, jedynym wyborem było umieszczenie danych strukturalnych (takich jak XML) w dużej kolumnie. Relacyjne bazy danych dodają funkcje, takie jak indeksowanie i dopasowanie, aby to obsługiwać.
Natomiast, że z Mongo, gdzie tylko rzecz w bazie danych dokumentów. Ale to inny temat.
EDYCJA: podstawową ideą zorientowania na dokumenty jest: wyciąganie danych, manipulowanie nimi i odsuwanie ich w całości. Czasami, na przykład gdy przesyłasz dokument do klienta, po prostu chcesz wysłać całość jako obiekt blob i pozwolić mu sobie z tym poradzić. Korzyścią (i wadą) jest elastyczność. Walidacja i poprawność dokumentu odbywa się poza bazą danych.
EDYCJA EDYCJA: Kolejny kontrast. Wyobraź sobie zapisywanie obrazów JPG lub dokumentów Word w kolumnie bazy danych.
Jakie są zalety przechowywania drzewa (XML) na liście krotek (tabela bazy danych)?
Nie ma powodu, dla którego XML nie powinien być kwerytujący się z DBMS przy użyciu np. XPath lub SPARQL.
Według mnie są to po prostu dwie różne struktury danych. I nie ma powodu, dla którego nie powinny być ze sobą osadzone.
Możesz sprawdzić przyczyny, dla których typ danych JSON został dodany w PostgreSQL. Myślę, że stosuje się wiele takich samych argumentów. Tyle że w przypadku XML / XSD możliwa jest jeszcze większa walidacja.
Cóż, XML (lub JSON) jest całkiem dobry do przechowywania metadat z hierarchią. Jakie są alternatywy? Może tabela metadanych z refid / key / value / depth? Jest to trochę kłopotliwe (ale prawdopodobnie lepiej jest przesyłać zapytania, jeśli musisz to zrobić). Przechowywanie niektórych danych xml dotyczących dokumentu (wiersza w tabeli dokumentów) jest dość wygodne, gdy chcesz przechowywać niektóre hierarchiczne informacje bez konieczności polegania na zewnętrznej tabeli lub dodawania 1 kolumny na „typ” informacji.
Powiedziałbym, że to zła praktyka, ponieważ zapychasz w inny sposób wydajne miejsce do przechowywania nieefektywnymi tagami, które nie muszą tam być, jeśli podejmujesz wysiłek, aby przeanalizować informacje. XML ma ohydny narzut pamięci w porównaniu do danych, które opisuje, ponieważ potrzebujesz jednego znacznika dla każdej kolumny dla każdego wiersza. Dla porównania, dane przeanalizowane i zapisane w formacie relacyjnym mają RAZ zapisaną nazwę kolumny. Przez kilkanaście wierszy na dev. pole, wielka sprawa, ale widziałem, jak programiści zakładają, że jest on skalowalny do milionów wierszy. Może to stanowić 100 GB narzutu dla kilkudziesięciu GB danych, co stwarza wyzwania operacyjne. Zasadniczo zrzekasz się odpowiedzialności za siebie i naciskasz na ludzi, którzy muszą wspierać bzdury, które napisałeś.
Dlaczego więc nie przechowywać go DALEJ od danych operacyjnych we własnej bazie danych? Lub zgodnie z przeznaczeniem - w plikach płaskich? Prawdopodobnie nigdy więcej się na niego nie spojrzy, więc dlaczego nie usunąć go z wydajności systemu operacyjnego? Pamiętaj, że XML jest TYLKO po to, aby dostarczyć opis schematu danych, który w innym przypadku nie byłby widoczny ze względu na różnice w protokołach przechowywania między systemami. I o to chodzi, nie ma w tym nic sprytnego. Przechowywanie 10-krotnej kwoty narzutu dla określonej ilości danych oznacza po prostu, że jesteś niechlujnym programistą, który nie przemyślał sprawy i nie można go przetworzyć na przetwarzane dane w rozsądny, wydajny, szybki do zapytania format. Przestań wkładać wysiłek w wsparcie operacyjne i MYŚL o tym, jak lepiej obsługiwać dane po „ otrzymałem to byłby mój telefon. Przechowywanie danych jako XML po ich otrzymaniu nie ma obrony, ponieważ spełniło swoje zadanie.