Kiedy używać typu danych XML


12

Jestem odpowiedzialny za utworzenie bazy danych projektu. Mamy pola, które rzadko mają wartość (1 na 10 000 rekordów) i staram się znaleźć najlepszy sposób przechowywania tego w bazie danych.

O ile widzę, mam 3 opcje:

  1. Dodaj kolumnę w tabeli dla każdej dodatkowej wartości
  2. Dodaj połączoną tabelę, która odwołuje się do oryginalnej tabeli i ma rekordy tylko tam, gdzie musimy przechowywać wartość
  3. Użyj typu danych XML w oryginalnej tabeli i zapisz w nim wszystkie wartości.

Czy są jakieś inne opcje, których nie rozważałem?

Próbuję wypracować zalety i wady każdej metody. O ile mogę stwierdzić, 1 będzie najłatwiejszy, a 2 zajmie najmniej miejsca, ale staram się znaleźć wiele zasobów dla 3.


1
Aby dodać osobistą wulgaryzację przeciwko nadużyciom XML w bazie danych, odpowiedziałbym bezpośrednio na pytanie w tytule i powiedziałem gruby tłuszcz: NIGDY! Jeśli chodzi o samą treść pytania, pozwolę kolegom pomóc, ponieważ masz już bardzo dobre odpowiedzi :-). PS: właściwie możesz zignorować moje pierwsze zdanie.
Marian

Ile dodatkowych pól mówisz? I czy mają sens być częścią tego samego bytu?
Andrew Bickerton,

Odpowiedzi:


12

Wydaje się, że to, czego potrzebujesz, to rzadkie kolumny i przefiltrowane indeksy i przejdź do opcji 1. Są to w pełni obsługiwane i udokumentowane funkcje dokładnie dla tego scenariusza.

Aparat baz danych SQL Server używa słowa kluczowego SPARSE w definicji kolumny, aby zoptymalizować przechowywanie wartości w tej kolumnie. Dlatego gdy wartość kolumny to NULL dla dowolnego wiersza w tabeli, wartość ta nie wymaga przechowywania.

Nie wyobrażam sobie, aby rozwiązanie XML działało dobrze w tym scenariuszu, będzie miało ogromny narzut redundantnych metadanych i będzie powolne w wyszukiwaniu.


1
Myślę, że szukam rzadkich kolumn. Oczekuję, że bardzo mała ilość danych będzie przechowywana w prawdopodobnie kilku kolumnach w niektórych tabelach.
Matthew Steeples

Nie jestem pewien, czy dobrze to czytam, ale zgodnie z tym linkiem rzadkie kolumny są w zasadzie implementacją bazy danych tego, czego szukałem 3, czyż nie? blog.sqlauthority.com/2008/07/14/…
Matthew Steeples

Jeśli jest on tak wewnętrznie zaimplementowany (a nie wiem, że tak, to tylko czyjś blog), nigdy nie będziesz musiał zajmować się ani parsować XML - zachowa się dokładnie tak jak zwykła tabela (z wszelkimi ograniczeniami) na typach danych)
Gajusz

5
  1. Nullable kolumna nie zajmuje miejsca, jeśli zmienna długość w SQL Server. Fakt bycia NULL jest przechowywany w bitmapie NULL . W razie potrzeby można go zindeksować za pomocą filtrowanych indeksów, aby zignorować kolumny NULL.

  2. Dodaje złożoności, gdy weźmiesz pod uwagę punkt 1.

  3. Nie rób Trudno wyszukiwać, analizować etc: ty będziesz tego żałował później

Zależy to również od rozmiaru: czy będzie to char (1000) dla kilku miliardów wierszy? Lub tinyint na 100 000 wierszy? Jeśli to drugie weźmie pod uwagę dodatkową złożoność punktu 2: nie warto.


Czy masz odniesienie, że null kolumna, która jest null, nie zajmuje miejsca. Miałem świadomość, że to, czy jest ona pusta, czy nie, było przechowywane w pustej mapie bitowej, ale dla pól o stałej długości pomyślałem, że dane są nadal przechowywane w tabeli. Typem danych, którego będę używać dla większości tych wartości, są pieniądze (czyli 8 bajtów)
Matthew Steeples

1
@Matthew Steeples: Powiedziałem, że zmienna długość nie zajmuje już miejsca. I dla odniesienia sqlskills.com/BLOGS/PAUL/category/On-Disk-Structures.aspx#p41 Jak wiersze dla tych 8 bajtów?
gbn

W tej chwili mamy 500 000 wierszy, ale będziemy się rozwijać (miejmy nadzieję) w tempie około 1 miliona w ciągu tygodnia, kiedy będziemy już w pełni funkcjonować.
Matthew Steeples

3

W SQL Server 2008 masz dodatkową opcję korzystania z rzadkich kolumn, które zostały zaprojektowane specjalnie dla wspomnianej sytuacji.

Ich dodatkową zaletą jest to, że można je wyświetlać jako połączony obiekt XML za pomocą XML COLUMN_SET lub odwoływać się do nich indywidualnie, a także zapewniają ogromną oszczędność miejsca.

Sprawdź następujący artykuł na blogu, aby uzyskać więcej informacji: http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server-2008-Sparse-columns-and-XML-COLUMN_SET.aspx


-4

Czwarta opcja: nie używaj tabel. Tabele są bardzo źle dostosowane do tego rodzaju danych (w rzeczywistości do wszelkiego rodzaju danych, które nie zostały przymusowo dopasowane w formie tabelarycznej). Wystarczy użyć XML.


3
-1 ponieważ prawdą jest, że opcja „nie używaj tabel” jest opcją , odpowiedź wyraźnie wskazuje na strukturę tabel i nie przekazuje pomocnej odpowiedzi.
Andrew Bickerton,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.