Kiedy powinienem używać XML zamiast SQL? [Zamknięte]

Od kilku lat pracuję nad aplikacjami internetowymi opartymi na bazach danych, a ostatnio podjąłem się projektu obejmującego CMS obsługujący XML. To skłoniło mnie do zastanowienia się nad użyciem XML / XSLT w ogóle i w jakich sytuacjach byłoby to bardziej przydatne niż podejście, z którego zawsze korzystałem, polegające na przechowywaniu wszystkich moich danych w (My) bazie danych SQL, a następnie PHP / Python / etc. aby w razie potrzeby pracować z nim w sieci.

Jest oczywiście coś, czego tutaj nie „rozumiem”. Czy ktoś mógłby mi podać przykłady zastosowań, w których przechowywanie danych w plikach XML zamiast w bazie danych byłoby lepsze?

Cytując tę książkę (efektywny XML: 50 konkretnych sposobów ulepszenia XML):

„XML nie jest bazą danych. Nigdy nie miała być bazą danych. To nigdy nie będzie baza danych. Relacyjne bazy danych to sprawdzona technologia z ponad 20-letnim doświadczeniem wdrożeniowym. Są to solidne, stabilne, użyteczne produkty. Oni nie odchodzą. XML to bardzo przydatna technologia do przenoszenia danych między różnymi bazami danych lub między bazami danych a innymi programami. Jednak sama w sobie nie jest bazą danych. Nie używaj go jak jeden ”.

Myślę, że to podsumowuje, choć trochę dosadnie. XML to format wymiany danych. Można mieć biblioteki parsujące XML, które mogą wysyłać zapytania do DOM z wyrażeniami XPath, ale to nie to samo, co DBMS. Możesz zbudować DBMS z interfejsem DOM / XPath, ale aby uzyskać właściwości ACID lub skalować do dużych zbiorów danych, musisz zaimplementować silnik DBMS i format danych z indeksami, rejestrowaniem i innymi artefaktami DBMS - co (z definicji) sprawia, że to coś innego niż XML.

Użyj XML do tworzenia plików, które należy wysłać do innych aplikacji. XML jest bardziej odpowiedni jako format wymiany danych niż jako format przechowywania danych.

Poniższy link nie jest zły do ​​opisania w przypadku korzystania z XML: Dlaczego powinienem używać XML?

SQL to dobre dane tabelaryczne - dane, które łatwo mieszczą się w wierszach i kolumnach. XML jest dobry dla danych hierarchicznych - danych, które mają kilka poziomów o różnych rozmiarach.

SQL jest dobry do przechowywania i wyszukiwania. XML jest dobry do przesyłania i formatowania.

1) Kiedy musisz wymieniać swoje dane z innymi. XML to „ lingua franca ” sieci - w przeciwieństwie do pliku bazy danych prawie każdy może go czytać i interpretować.

2) Gdy ilość danych jest mała i nie musisz wykonywać złożonych zapytań. Pliki XML są dobre do takich rzeczy, jak przechowywanie konfiguracji lub szablonów dokumentów.

3) Gdy nie masz wielu pisarzy próbujących uzyskać dostęp do tych samych danych. Bazy danych SQL zawierają mechanizmy współbieżności, które działają dla Ciebie za kulisami. Bazy danych SQL mogą obsługiwać indeksy do szybkiego wyszukiwania informacji o dużych zestawach danych ...

Rzeczy, do których używam XML:

• Utrwalanie hierarchii obiektów.
• Przenoszenie danych z jednego procesu lub maszyny do innego.
• Dane, które zmieniają się rzadko, jeśli w ogóle; ustawienia konfiguracji i tym podobne.
• Ponieważ dane wejściowe do XSLT ulegają transformacji: ogólnie rzecz biorąc, jeśli jeden z moich programów emituje HTML, używa do tego XSLT, więc dane źródłowe będą reprezentowane jako XML w niektórych
• Znaczniki tekstowe. (Nie zapominajmy o tym!)

Te przypadki użycia i przypadki użycia bazy danych nie pokrywają się zbytnio. Trochę, ale niewiele.

Jak na ironię, obecnie najbardziej wykorzystuję XML w aplikacji komputerowej, która buduje w pamięci ADO DataSet i używa metod WriteXml i ReadXml DataSet, aby go utrwalić i odzyskać. Używam ADO, ponieważ znacznie łatwiej jest dynamicznie zbudować model danych zdefiniowany przez metainformation przy użyciu ADO, niż zaimplementować własny model obiektowy dla zadania.

Oto przypadek, który wygląda na to, że używam XML jako bazy danych. Ale ja naprawdę nie jestem. Używam modelu obiektowego, który ma zaimplementować wiele funkcji podobnych do bazy danych i używam XML jako formatu trwałości.

Uważam, że istnieje wiele komercyjnych aplikacji, które intensywnie wykorzystują XML jako nośnik danych. Zrobiłem to dla aplikacji do planowania projektów, w której użytkownik przechowuje każdy projekt w swoim własnym pliku. Aplikacja działa na pendrive i nie wymaga instalacji. Wszystkie dane są pobierane z XML i przetwarzane w pamięci, więc getRecord (id) działa szybko.

Więc moja odpowiedź brzmiałaby ... kiedy dane są wystarczająco małe, aby przechowywać je w pamięci, baza danych jest nadmiernie niszczona.

Nie.

Wypróbuj opcję WYBIERZ autora z książki

Zawsze, gdy nie masz luksusu posiadania bazy danych (pomyśl o aplikacjach dla pojedynczego użytkownika) lub potrzebujesz bardzo lekkiego formatu przechowywania.

Jak wspomniano w poprzednim plakacie, format wymiany.

Zarówno XML, jak i RDMS mogą być używane jako magazyny danych, ale każda implementacja ma swoje zalety i wady.

Używanie XML do przechowywania danych dla aplikacji internetowej zwykle nie stanowi dużego problemu, dopóki nie zaczniesz zajmować się dużymi ilościami danych lub nie zdecydujesz, że chcesz odkryć inne informacje ze swoich danych (na przykład: eksploracja danych). Innymi słowy, przechowywanie dużych ilości plików XML dla źródła danych nie jest bardzo skalowalne, ale ułatwia przenoszenie danych. XML może być również używany do serializacji złożonych obiektów w formacie nierelacyjnym, co może wyeliminować potrzebę ORM, jeśli możesz serializować / deserializować swoje obiekty bezpośrednio z XML

RDMS (bazy danych) są zwykle bardziej skalowalne, oferują większą obsługę współbieżności i są znacznie szybsze podczas pracy z dużymi ilościami danych. Model relacyjny ułatwia późniejsze przeszukiwanie danych. Bazy danych cierpią z powodu niedopasowania impedancji relacyjno-obiektowej ( http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch ), co może wymagać napisania brzydkiego kodu lub użycia złożonych ORMów.

Poszedłbym, gdybym miał ograniczone bazy danych mysql na moim hoście, wtedy zobaczyłbym możliwość wykorzystania XML jako magazynu danych.

Oto przykład użycia XML z SQL: Uwierzytelnieni użytkownicy czytają i zapisują dane w różnych bazach danych, z których nie wszystkie są tym samym DBMS. Użytkownicy firmy A używają danych z lokalnej bazy danych SQL Server. Użytkownicy firmy B używają danych ze zdalnej bazy danych Oracle. I tak dalej. Kilkanaście różnych baz danych, każda z nieco innymi schematami dla tych samych podstawowych danych.

Deweloper serwisu WWW nie ma możliwości tworzenia procedur składowanych w zdalnych bazach danych. SQL musi być wysyłany bezpośrednio z aplikacji internetowej do bazy danych. Ponieważ każda baza danych ma nieco inną składnię i schemat SQL, konieczne jest użycie innego SQL dla każdej z 12 baz danych dla tej samej operacji (SELECT, INSERT itp.).

Jedną z opcji osadzania instrukcji SQL w aplikacji internetowej jest umieszczenie ich w plikach XML. Każdy plik XML zawiera zestaw instrukcji SQL dla jednej z kilkunastu baz danych. Kod określa, do której bazy danych uzyskuje dostęp zalogowany użytkownik, i pobiera odpowiedni kod SQL z określonego pliku XML.

Podobnie jak w przypadku procedur składowanych, kod SQL w pliku XML można aktualizować bez zatrzymywania lub ponownego kompilowania aplikacji.

Niektóre aplikacje używają plików XML do przechowywania konfiguracji, ja wolę do tego używać SQLite .

Nigdy bym tego nie zrobił użyłbym żadnego XMLa do przechowywania moich danych.

Używamy transformacji XSLT jako warstwy abstrakcji danych w naszej aplikacji SOA. Wszystkie obiekty przesyłają sobie nawzajem dane w XSLT, więc jest tylko jeden język, który muszą zrozumieć. Z wyjątkiem konektora bazy danych, który musi mieć możliwość przekształcenia danych w SQL, aby wysłać je do bazy danych.

W ten sposób nie masz generowania ciągów SQL rozproszonych po zillionach obiektów w Twojej aplikacji. Ułatwia konserwację.