Temat: [MSSQL] Struktura generyczna z wykorzystaniem XML

Witam,

stanąłem niedawno przed problemem zaprojektowania mocno zmiennej struktury, której efektywność miała duże znaczenie w kontekście systemu. Skończyło się na standardowym rozwiązaniu (5 tabel: typ, instancja, parametr, słownik parametrów, wartość parametru). Po drodze czytałem nieco o rozwiązaniach xmlowych, acz czas nie pozwolił by móc to solidnie przetestować i sprawdzić w akcji. Mimo wszystko hak zagięty w głowie pozostał ;)

Serwer: MSSQL2005

MSSQL posiada wsparcie dla obsługi XML, włącznie z ciekawymi indexami. Inna rzecz, że są one stosunkowo drogie (podstawowy, wymagany do uzycia innych jest większy od indeksowanego xml), a wyszukiwanie w tym projekcie dotyczyło parametrów, które przewidywane były jedynie dla kilku typów. Stąd tworzenie indeksu dla każdej instancji, z których większość nigdy go nie wykorzysta - odpada. Rozwiązaniem byłby rozdział na dwa pliki xml, jeden z parametrami do wyszukiwania a drugi nie, i użycie zapytań XQuery, które mogą dotyczyć kilku źródeł xml w sposób przeźroczysty dla użytkownika. Aczkolwiek, implementacja XQuery zapewniana przez MSSQL nie umożliwia wyszukiwania z kilku źródeł. Można wprawdzie użyć odpowiedniej konstrukcji FOR XML dla wygenerowania pośredniego pliku sumującego, ale tworzony jest wówczas nowy plik, do tego bez indeksów. Chyba, żeby posłużyć sie zewnętrznym procesorem XQuery, takim jak DataDirect, ale tu z kolei nie wiem, czy wykorzysta on indeksy MS (znajac xenofobię MS to pewnie nie ;P) i czy też nie generuje sobie w tle po prostu pliku zbiorczego...

Osobnym problemem pozostaje walidacja. MSSQL umożliwia stosownie XML Schema do walidacji trzymanych zasobów, nawet jest to sugerowane gdyż jej obecność przyśpiesza wykonywanie zapytań, ale jest ona trzymana przezeń "gdzieś" i nie ma do niej bezpośredniego dostępu. A mimo wszystko dobrze byłoby mieć ją dostępną w aplikacji, np. po to by utworzyć formularz z polami dostępnymi w typie, czy by ograniczyć ilość błędnych zapytań do BD (zresztą w ogóle wolałbym przeprowadzić walidację poza BD). Rozwiązaniem byłoby trzymanie Skimy jako osobnego pliku xml w BD, ale tu pojawia się konieczność zapewnienia odpowiedniej synchronizacji między xml w BD i skimą faktycznie używaną przez BD do walidacji...

Ten temat można jeszcze olać ;) jako że MS umożliwia rezygnację z używania XML Schema, i trzymanie xml jako untyped. Co jednak odbija się na efektywności zapytań.


Idealnym rozwiązaniem byłby rozdział danych na dwa pliki, o czym wspomniałem już wcześniej - jeden z danymi mogącymi być częstym obiektem zapytań, i im przydzieliłbym Skimę i indeksy, a pozostałe trzymałbym bez indeksów, bez wsparcia MS dla XML Schema, którą trzymałbym dla tego pliku w bazie jako niezależny xml. Acz o wątpliwościach związanych z tym rozwiązaniem już pisłem...

Pozostaje oczywiście kwestia wydajności xml w BD w tym przypadku w ogóle :]