Używanie XML do przechowywania danych [zamknięte]

Myślałem o formacie XML i następującym cytacie:

„XML nie jest bazą danych. Nigdy nie miał być bazą danych. To nigdy nie będzie baza danych. Relacyjne bazy danych to sprawdzona technologia z ponad 20-letnim doświadczeniem we wdrażaniu. Są to solidne, stabilne, użyteczne produkty. Nie odchodzą. XML jest bardzo przydatną technologią do przenoszenia danych między różnymi bazami danych lub między bazami danych i innymi programami. Jednak sama nie jest bazą danych. Nie używaj go jak jeden. ”- Efektywny XML: 50 konkretnych sposobów na ulepszenie twojego XML autorstwa Elliotte Rusty Harold (strona 230, część 4, pozycja 41, akapit drugi)

Wydaje się to naprawdę podkreślać, że XML nie powinien być wykorzystywany do przechowywania danych i powinien być używany tylko do współdziałania programu z programem.

Osobiście się nie zgadzam, a app.configplik .NET używany do przechowywania ustawień programu jest przykładem przechowywania danych w pliku XML. Jednak w przypadku baz danych zamiast konfiguracji itp. XML nie powinien być używany.

Aby rozwinąć mój punkt, wykorzystam dwa przykłady:
A) Dane o klientach z polami, które są na jednym poziomie, tj. Istnieje szereg pól odnoszących się do jednego klienta bez dzieci
B) Dane o konfiguracji aplikacji, w której pola zagnieżdżone a właściwości mają sens

Więc moje pytanie brzmi: czy nadal jest to prawidłowe oświadczenie i czy teraz można przechowywać dane przy użyciu XML?

EDYCJA: Wysłałem e-mail do autora tego cytatu z prośbą o jego wkład / dodatkowy kontekst.

Ten cytat nie dotyczy ogólnie używania XML jako formatu pamięci (dla którego jest to w porządku, w zależności od wymagań), ale do przechowywania typu bazy danych.

Kiedy ludzie mówią o bazach danych, zwykle mają na myśli systemy pamięci masowej, które przechowują ogromne ilości danych, często w zakresie gigabajtów lub terabajtów. Baza danych jest potencjalnie znacznie większa niż ilość dostępnej pamięci RAM na serwerze, który ją przechowuje. Ponieważ nikt nigdy nie potrzebuje wszystkich danych w bazie danych na raz, bazy danych powinny być zoptymalizowane pod kątem szybkiego pobierania wybranych podzbiorów ich danych: po to jest SELECTinstrukcja, a relacyjne bazy danych, a także rozwiązania NoSQL optymalizują swój wewnętrzny format przechowywania w celu szybkiego wyszukiwanie takich podzbiorów.

XML jednak nie spełnia tych wymagań. Ze względu na zagnieżdżoną strukturę znaczników niemożliwe jest ustalenie, gdzie w pliku przechowywana jest pewna wartość (pod względem przesunięcia bajtu do pliku) bez przejścia całego drzewa dokumentów, przynajmniej do dopasowania. Relacyjna baza danych ma indeksy, a wyszukiwanie wartości w indeksie, nawet przy prymitywnej implementacji wyszukiwania binarnego, jest pojedynczym wyszukiwaniem O (log n), a następnie uzyskanie rzeczywistych wartości jest niczym innym jak wyszukiwaniem pliku (np. fseek(data_file_handle, row_index * row_size)), czyli O (1). W pliku XML najskuteczniejszym sposobem jest uruchomienie analizatora składni SAX nad dokumentem, wykonując strasznie dużo odczytów i poszukiwań, zanim dotrzesz do rzeczywistych danych; nie da się tego uzyskać lepiej niż O (n), chyba że użyjesz indeksów, ale wtedy będziesz musiał odbudować cały indeks dla każdego wstawienia (patrz poniżej).

Wstawianie jest jeszcze gorsze. Relacyjne bazy danych nie gwarantują kolejności wierszy, co oznacza, że ​​mogą po prostu dodawać nowe wiersze lub zastępować wiersze oznaczone jako „usunięte”. Jest to niezwykle szybkie: DB może po prostu przechowywać wokół siebie pulę zapisywalnych lokalizacji; uzyskanie wpisu z puli to O (1), chyba że pula jest pusta; w najgorszym przypadku pula jest pusta i należy utworzyć nową stronę, ale to także O (1). Natomiast baza danych oparta na XML musiałaby przenieść wszystko po punkcie wstawienia, aby zrobić miejsce; to jest O (n). Kiedy pojawiają się indeksy, sprawy stają się jeszcze bardziej interesujące: typowe indeksy relacyjnych baz danych można aktualizować przy stosunkowo niskiej złożoności, powiedzmy O (log n); ale jeśli chcesz zindeksować swoje pliki XML, każde wstawienie potencjalnie zmienia lokalizację na dysku każdej wartości w dokumencie, więc musiszodbuduj cały indeks . Dotyczy to również aktualizacji, ponieważ aktualizacja, powiedzmy, zawartości tekstowej elementu, może zmienić jego rozmiar, co oznacza, że ​​kolejne pliki XML muszą się zmieniać. Relacyjna baza danych wcale nie musi dotykać indeksu, jeśli zaktualizujesz nieindeksowaną kolumnę; baza danych XML musiałaby odbudować cały indeks dla każdej aktualizacji, która zmienia rozmiar zaktualizowanego węzła XML.

To najważniejsze wady, ale jest ich więcej. XML jest bardzo szczegółowy, co jest dobre w komunikacji między serwerami, ponieważ zwiększa bezpieczeństwo (serwer odbierający może wykonywać wszelkiego rodzaju kontrole integralności XML, a jeśli coś pójdzie nie tak podczas przesyłania, dokument prawdopodobnie nie potwierdzi ). W przypadku pamięci masowej jest to jednak zabójstwo: nierzadko zdarza się, aby narzut danych XML wynosił 100% lub więcej (nierzadko obserwuje się narzuty w zakresie 1000% dla rzeczy takich jak komunikaty SOAP), podczas gdy typowe relacyjne przechowywanie DB schematy mają tylko stały narzut metadanych tabeli, a także niewielki bit na wiersz; większość kosztów w relacyjnych bazach danych pochodzi ze stałych szerokości kolumn. Jeśli masz terabajt danych, narzut 500% jest po prostu niedopuszczalny z wielu powodów.

XML jest kiepski do przechowywania danych. Po pierwsze, jest bardzo gadatliwy. Dane przechowywane w pliku XML zajmą znacznie więcej miejsca na dysku niż te same dane przechowywane w dowolnym rozsądnym systemie baz danych. W rekordzie XML nazwa określonego pola będzie przechowywana dwukrotnie, wraz z ciągiem reprezentacji danych. Na przykład, aby zapisać pojedynczą liczbę całkowitą w polu o nazwie „foobar”, otrzymujesz ten 19-bajtowy ciąg:

<foobar>42</foobar>

Z drugiej strony prawdziwa baza danych będzie przechowywać tę wartość jako jedną wartość całkowitą, zajmując 4 bajty. Jeśli Twoja baza danych jest mała, nie znaczy to wiele, ale jeśli masz 10 000 rekordów, to jest problem.

Po drugie, plik XML musi być analizowany z tekstem za każdym razem, gdy plik jest czytany. W przypadku powyższego pola prawdziwa baza danych po prostu odczytuje dane binarne do pamięci z przesunięcia, o którym wie, że zapisało pole „foobar”. Jeśli plik jest zapisany jako XML, musi odczytać pole „foobar”, przeanalizować ten tekst , określ, jakie to pole, a następnie przeanalizuj ciąg „42” i przekonwertuj go na binarny 42.

Zatem kary za wydajność za używanie XML są ogromne. Zaletą XML jest to, że jest on w pewnym stopniu czytelny dla człowieka i pozwala na łatwy transfer danych między całkowicie oddzielnymi systemami. Żadna z tych zalet nie dotyczy lokalnej bazy danych.

Jedynym wyjątkiem są pliki konfiguracyjne, które są na ogół małe i zwykle muszą być edytowalne przez ludzi.

Baza danych XML będzie absolutnie większa i wolniejsza niż jakikolwiek rozsądny system SQL. O ile nie znajdziesz przewagi przeciwwagi dla czytelności lub współdziałania ludzi, po prostu nie ma sensu używać jej do przechowywania danych.

XML jest wykonalny w zależności od kontekstu. Jeśli twoje dane są dość statyczne i niewiele się zmieniają (na przykład dane przykładowe), tak XML jest dobrym zastosowaniem.

Ustawienia konfiguracji, przykładowe dane (nawet jeśli są to miliony wierszy, ale rzadko się zmieniają), wszystkie są dobrym zastosowaniem XML.

Odczytywanie / zapisywanie na dysku twardym jest kosztowne, znacznie więcej niż dostęp do danych ze stosu Oracle / Sql.

Wydaje się to naprawdę podkreślać, że XML nie powinien być wykorzystywany do przechowywania danych i powinien być używany tylko do współdziałania programu z programem.

Twoja przesłanka jest wadliwa.

Cytowany przez Ciebie akapit mówi w rzeczywistości, że XML nie zastępuje bazy danych , a nie, że nie należy go używać do przechowywania danych .

Oczywiste jest, że plik ustawień nie jest tym samym, co baza danych, dlatego można (i należy?) Stosować różne technologie.

Popraw mnie, jeśli się mylę, ale wydaje ci się, że masz więcej doświadczenia z językami znaczników niż z bazami danych. Jeśli masz trochę doświadczenia z bazami danych, zorientujesz się, w których domenach są odpowiednie dwie różne technologie.

To jest naprawdę subiektywne. Ten cytat to czyjaś opinia, człowiek.

Szczerze mówiąc, myślę, że XML jest realną alternatywą dla bazy danych, ponieważ ma wiele zalet w stosunku do RDMS, w tym niski koszt narzutu, co oznacza tańsze miejsce do przechowywania (szczególnie przy korzystaniu z usługi hostingowej, która pobiera opłaty za bazy danych osobno).

Spójrz na dasBlog i BlogEngine . Obie aplikacje domyślnie używają xml do przechowywania.

To mówi. To nie jest RDMS, a jeśli masz dużą zmienność (wiele aktualizacji, wstawień lub usunięć) w swoich danych lub potrzebujesz wysokiej dostępności, skorzystaj z bazy danych. XML doskonale nadaje się do przechowywania drobnych rzeczy, takich jak dane konfiguracyjne i dane o niskiej lotności.

moje pytanie brzmi: czy nadal jest to prawidłowe oświadczenie i czy teraz można przechowywać dane przy użyciu XML?

Widzę twój przykład w tobie na temat plików konfiguracyjnych .NET. Można jednak użyć dowolnego innego formatu pliku. W rzeczywistości w dawnych czasach takie ustawienia były przechowywane w zwykłych plikach tekstowych zwanych plikami INI.

Widzę, że oświadczenie, które przedstawiłeś w kolorze szarym, jest poprawne i poprawne, jeśli zdefiniujesz bazę danych jako system oprogramowania.

Definicja XML w XML-Definition stwierdza, że ​​„(XML) to język znaczników, który definiuje zestaw reguł kodowania dokumentów w formacie, który jest zarówno czytelny dla człowieka, jak i maszynowy”.

Ta definicja skupia się raczej na czytelności i języku niż na mechanizmach zarządzania danymi.

W porównaniu do RDBMS, XML nie zapewnia środków do losowego wstawiania i usuwania wierszy w pliku XML. Na przykład, jeśli masz 1000000 wierszy i chcesz losowo usunąć wiersze, nawet w środowisku pojedynczego użytkownika, plik oparty na XML nie byłby dobrym wyborem dla bazy danych. Ponadto XML nie zapewnia żadnych natywnych mechanizmów blokowania danych. W rzeczywistości, ponieważ XML nie jest oprogramowaniem, wszystkie właściwości ACID (atomowość, spójność, izolacja, trwałość), które gwarantują, że transakcje w bazie danych są przetwarzane w sposób niezawodny w środowisku współużytkowanym, są rozwijane przez programistę (z wyjątkiem Trwałości). XML nie ma solidnej specyfikacji do obsługi integralności danych w plikach XML, nie mówiąc już o różnych serwerach (np. Plik xml klienta i plik xml zamówień - brak FK do egzekwowania integralności).

Powyższe nie stanowi wyliczenia tego, czego brakuje XML, może natomiast służyć jako szybkie uzasadnienie stwierdzenia, że ​​XML nie jest oprogramowaniem bazodanowym .

XML nigdy nie miał być bazą danych ani go zastępować.

XML jest definiowany głównie dla dokumentów internetowych allows for the creation of customized tags for individual information fields., których nigdy nie można osiągnąć za pomocą relacyjnego scentralizowanego zarządzania danymi.

Dlaczego tak naprawdę chcesz używać XML do przechowywania danych ? W końcu to język ...

Chociaż można argumentować, że jest to elastyczny i łatwy do zrozumienia format, ma to zastosowanie tylko wtedy, gdy trzeba ręcznie edytować pliki. Kiedy faktycznie wchodzisz w interakcję z bazą danych ze wspólnym interfejsem (pobierz dane X, które spełniają wymagania Y i Z, przechowuj / aktualizuj dane X, ...), zalety te stają się nieważne.

Krótka odpowiedź: to zależy.

Długa odpowiedź: z mojego punktu widzenia zależy to w dużej mierze od ilości danych, które chcesz przechowywać. Na przykład, jeśli masz kilka obiektów w aplikacji podczas uruchamiania i chcesz je zapisać po uruchomieniu narzędzia, plik XML jest w porządku. Jeśli jednak Twój sklep internetowy ma 5000 klientów i jeszcze więcej zamówień, baza danych byłaby bardziej odpowiednim miejscem do przechowywania danych.

Dodatkowo myślę, że przechowywanie ustawień w bazie danych, a nie w pliku takim jak app.config, w większości przypadków nie jest zbyt przydatne, ale nie sądzę, aby ten przykład był błędny.

XML to doskonały wybór dla ustawień konfiguracji. Pliki XML są nie tylko łatwe do parsowania / wyróżniania w środowisku IDE, ale są również bardzo łatwe do edycji dla osób niebędących programistami. Uważam je za niezwykle przydatne w scenariuszach tworzenia stron internetowych, w których zadania konserwacyjne są wykonywane przez projektantów i menedżerów treści.

XML zwykle nie powinien być wykorzystywany jako podstawowe źródło danych dla jakichkolwiek nietrywialnych aplikacji. Sam narzut związany z serializacją / deserializacją wymaga innego rozwiązania.

Termin baza danych może odnosić się zarówno do danych surowych, jak i do systemu zarządzania bazą danych. Ta definicja robi dużą różnicę w całym argumencie.

Jeśli użyjemy definicji RDBMS, wówczas XML ma bardzo niewiele w tym sensie. Dostajesz bardzo niewiele pod względem gwarancji ACID (aby to osiągnąć, musisz napisać własny kod). Jeśli potrzebujesz tych (i większość systemów transakcyjnych tego potrzebuje), masz już poważne kłopoty. Mógłbym podać listę setek funkcji uznawanych za oczywiste z RDBMS, które musielibyście wymyślić na nowo i ponownie wdrożyć. Pomyśl o modelach bezpieczeństwa, replikacji, kopiach zapasowych, żeby wymienić tylko kilka podstawowych.

W powyższym sensie nie, XML nie jest bazą danych i nie powinieneś próbować używać go jako bazy danych.

Jeśli użyjemy definicji „surowych danych”, XML wypada znacznie lepiej, ale nadal nie jest tak świetnie. Jednak, jak zauważyli inni, ogólnie rzecz biorąc jest to bardzo gadatliwy, zwykle pozbawiony kodowania binarnego, posiadający zduplikowane tagi itp. Są to kompromisy, dzięki którym XML może być czytelny dla człowieka - w zasadzie wydajność jest wrogiem tego wymogu . XML również nie jest szczególnie odpowiedni do nawet najprostszych sytuacji, w których rekordy są wstawiane w sposób ciągły. Zakładając, że chcesz, aby Twój plik XML był prawidłowy, potrzebujesz pojedynczego znacznika zamykającego, co oznacza, że ​​dołączenie rekordu oznacza, że ​​musisz przesunąć znaczniki w górę na końcu. Jest to dość drogie (skąd wiemy, gdzie zaczyna się ten znacznik? Co, jeśli istnieje wiele „tabel”, czy po prostu przesuwamy cały plik w górę?), A jeśli chcesz obejść ten problem, „

Są sytuacje, w których XML jest odpowiedni - pliki konfiguracyjne są doskonałym przykładem, ponieważ są zwykle małe, a czytelność dla ludzi jest doskonałą funkcją. Posiadanie bazy danych tylko dla pliku konfiguracyjnego może być przesadą.

Z drugiej strony bazy danych są doskonałe, gdy masz tysiące (lub miliony / miliardy) rekordów i wielu użytkowników jednocześnie je aktualizuje. Tak, XML nie jest bazą danych i nie należy jej używać w taki sposób. Twój przykład to jedna z tych sytuacji, w których nie potrzebujesz DB, a XML jest lepszym rozwiązaniem.

Widzę to w ten sposób: jeśli użyjesz XML jako bazy danych (powiedzmy, jako bazy danych dla systemu transakcyjnego), skończysz na nowo wymyślając i przepisując RDBMS . To naprawdę kiepski sposób na spędzenie czasu i energii. Myślę, że tak właśnie mówił ten cytat.

Zgadzam się, że nie jest to relacyjna baza danych. Myślę, że autor po prostu mówi w cytacie, aby nie używać go jako jednego.

To powiedziawszy, chociaż możesz go potrzebować lub nie. Jeśli tak naprawdę nie musisz wykonywać wielu zapytań o dane, a jedynie zamierzasz je zapisać, a następnie pobrać później na podstawie niektórych ograniczonych kryteriów zapytania, potrzebujesz przechowywania i pobierania DOCUMENT XML - a nie relacyjnej bazy danych.

Istnieje wiele aplikacji, które po prostu muszą przechowywać dokument z danymi w celu późniejszego pobrania. W takim przypadku nie ma sensu tworzyć schematu opartego na SQL, analizować XML, a następnie serializować go do bazy danych, aby później zrobić tylko odwrotność. Istnieje wiele narzutów kodu, które mogą być w to zaangażowane. Jest mniej, jeśli zrobisz to dobrze.

Możesz użyć narzędzi ORM, takich jak Hibernacja, i narzędzi, takich jak Apache Axis, w celu automatycznego wygenerowania praktycznie całego kodu potrzebnego do zbudowania usługi, która obsługuje proste operacje CRU. Trzeba by to oczywiście zapakować do uwierzytelnienia i być może zechcesz segregować dane na podstawie użytkownika, poziomu dostępu itp. Możesz nawet chcieć ograniczyć operacje, które dany użytkownik może wykonywać za pośrednictwem usługi SOAP dla przykład.

W tym sensie bardziej przypominasz zarządzanie treścią niż cokolwiek innego.