Я сьогодні обмірковував базу даних AdventureWorks і помітив, що в ряді таблиць ( HumanResources.JobCandidateі, Sales.Individualнаприклад) є стовпець, в якому зберігаються дані XML.
Що я хотів би знати, в чому полягає перевага зберігання даних вартості рядка таблиці баз даних у стовпчику іншої таблиці? Це не ускладнює запит на цю інформацію? Або припущення, що дані не потрібно запитувати, а просто потрібно зберігати?
Відповіді:
Оскільки не всі дані потрібно зберігати реляційно, а запис коду для обробки даних, переданих вами як XML для реляційного зберігання, займає багато часу (і дуже втомливо). Це особливо актуально, коли багато XML-даних надходить із систем, які викидають великі загальні відповіді.
Я часто бачив ситуації, коли повідомлення надходить від іншої системи, і нам не байдуже 98% того, що воно містить. Тож ми розбираємо його, щоб розділити 2%, про які ми піклуємось, зберігаємо це відносно, а потім зберігаємо все повідомлення на випадок, якщо нам буде потрібне будь-яке з решти 98% пізніше.
І SQL Server надає вам деякі інструменти та синтаксис OK-ish для роботи з XML у T-SQL, тому це не так, якби це абсолютно не виходить для спеціальних запитів таким чином, як це могло б бути, якщо ви зберігаєте, скажімо, вміст CSV.
І це виключає можливість того, що ви насправді хочете зберігати, це XML (наприклад, для підтримки та налагодження) ...
Якщо формат даних є нестабільним і підлягає можливим змінам, можливо, ви захочете скласти його як XML та ввести в базу даних у цій формі, тим самим уникнути подальшої зміни схеми бази даних.
З тієї ж дотичної точки, якщо дані надаються якоюсь зовнішньою системою і споживаються нею знову, і вони не в змозі надати вам постійний формат, це ви б зробили.
Це не ускладнює запит на цю інформацію?
SQL Server може запитувати XML-поля та змінні. Не обов’язково складно, але більше роботи, так. Але виконується.
З мого досвіду, дані XML зазвичай зберігаються і рідко запитуються, але часто витягуються, коли це необхідно, зазвичай, коли інша система потребує подання XML деяких даних, які можуть бути важкими або неможливими для генерації в ході реляційних даних. Дані XML можуть бути попередньо заповнені деяким іншим процесом.
Якщо ви можете уявити, як зберігати свої дані у двійковому потоці в краплі, то я думаю, ви можете уявити, як зберігати свої дані у форматі XML у краплі.
Звичайно, багато речей найкраще залишити в уяві уявителя.
Скажімо, електронні медичні записи, наприклад:
Оскільки ви, швидше за все, зберігаєте ASCII HL7 V2.x у полі в базі даних. Напевно, ви зможете зберігати HL7 V3.0 у полі в базі даних.
Тож перевага - зручність.
Зараз я працюю над проектом, який робить це. У нас є дані, які потрібно обробляти кілька разів, зберігати відносно. Однак обробка проводиться на Java, і там працювати з XML простіше. Отже, ми одноразово проходимо через реляційні дані і зберігаємо їх як XML у таблиці. Тоді ми можемо обробляти ці дані на Java одним запитом, що не приєднується, а не отримувати дані кожен раз, і обробляти ті самі дані знову і знову до вмісту нашого серця. Це набагато простіше і ефективніше.
Хороший приклад зберігання XML - це коли потрібно зберігати стани інтерфейсу в базі даних. Стан усіх переглядів додатків серіалізується і зберігається в базі даних, і не потрібно запитувати XML. Під станом інтерфейсу я маю на увазі порядок перегляду, розмір вікон тощо.
Часто ви отримуєте змішані дані, що є як XML, так і реляційними. (Чудовим прикладом цього є сховище документів, де кожен документ може мати поля метаданих, наприклад, заголовок, дата створення, власник тощо).
У цей момент вам потрібно вибрати три варіанти:
Варіант 3, мабуть, найчистіший, але також найдорожчий і найскладніший для впровадження, плюс вам не обов’язково потрібно розподіляти транзакції в не дуже великій системі. Варіант 2 не дуже хороший, оскільки рідні бази даних XML зазвичай вкрай погані при обробці реляційних даних (які ви, швидше за все, використовуєте в пошуку), а технологія в цілому менш зріла, ніж реляційна БД.
Тож це залишає вам варіант 1, як звичайно, не найкраще рішення, але, можливо, найменш поганий.
З мого досвіду, використання XML у базі даних закінчується тим, що саме так джерело даних зберігає їх, або ви додаєте їх у існуючу базу даних, щоб розширити функціональність таким чином, що не потрібно багато програмування баз даних для підтримки .
Якщо ви будете шукати нові дані часто, можливо, має сенс розділити XML на його складові частини. Якщо ні, то це може бути корисним способом збереження нечасто змінених даних.
Сподіваюся, це допоможе, Джеффе
Документи, орієнтовані на документи (aka NoSql) дуже популярні в наші дні:
http://en.wikipedia.org/wiki/Document-oriented_database
Немає жодної причини не можна використовувати орієнтовану на документи схему у реляційній базі даних. Можливо, ви не отримаєте однакових переваг у порівнянні з чимось на зразок Монго, але і недоліків у вас не буде.
Тривалий час, якщо ви хотіли використовувати орієнтоване на зберігання документів, ваш єдиний вибір - переміщення структурованих даних (наприклад, XML) у велику колонку. До реляційних баз даних додаються такі функції, як індексація та відповідність для їх підтримки.
Порівнюйте це з Монго, де у базі даних є лише речі. Але це вже інша тема.
EDIT: Основна ідея, орієнтована на документи, полягає в тому, що ви витягаєте дані, маніпулюєте ними та цілком повертаєте їх назад. Іноді, як, наприклад, коли ви передаєте документ клієнтові, ви просто хочете відправити всю річ як кльош і дозволити їм розібратися з цим. Перевага (і недолік) - гнучкість. Перевірка та коректність документа здійснюється за межами бази даних.
EDIT EDIT: Ще один контраст. Уявіть, що в стовпці бази даних зберігаються зображення JPG або Word документи.
Які переваги зберігання дерева (XML) у списку кортежів (таблиця бази даних)?
Немає жодної причини, чому XML не повинен бути підданий питанню від вашої СУБД, використовуючи, наприклад, XPath або SPARQL
Як я бачу, це просто дві різні структури даних. І немає причин, чому вони не повинні вбудовуватися одна в одну.
Ви можете шукати причини того, що тип даних JSON був доданий у PostgreSQL. Я думаю, що багато тих же аргументів застосовуються. За винятком того, що з XML / XSD можлива ще більша перевірка.
Ну, XML (або JSON) досить добре зберігати метадані з ієрархією. Які альтернативи? Таблиця метаданих, можливо, refid / ключ / значення / глибина, можливо? Це трохи громіздко (але, мабуть, краще для запиту, якщо вам це потрібно зробити). Зберігання деяких XML-даних про документ (рядок у таблиці документів) є досить зручним, коли ви хочете зберігати деякі ієрархічні дані, не покладаючись на зовнішню таблицю або додаючи 1 стовпець на "тип" інформації.
Я б сказав, що це було поганою практикою, оскільки ви засмічуєте інакше ефективне сховище неефективними тегами, які не повинні бути там, якщо ви докладете зусиль для розбору інформації. XML має жахливі накладні сховища порівняно з описаними даними, оскільки вам потрібен один тег для кожного стовпця для кожного рядка. Для порівняння, дані, розібрані та збережені у реляційному форматі, мають назву стовпця, що зберігається ONCE. За десяток рядів на деві. поле, велика справа, але я бачив, як розробники роблять припущення, що це масштабується до мільйонів рядків. Це може становити 100 ГБ накладних витрат на кілька десятків ГБ даних, що створює операційні проблеми. Ви в основному відмовляєтесь від відповідальності від себе і натискаєте на людей, які мають підтримати лайно, про яке ви написали.
Отже, чому б не зберігати його ЗА ВІДБАГО від оперативних даних, у власній базі даних? Або як задумано - у плоских файлах? Напевно, його більше ніколи не переглянуть, то чому б не усунути його від ураження продуктивності операційної системи? Пам’ятайте, що XML ТІЛЬКИ існує для надання опису схеми даних, яка в іншому випадку не була б очевидною через різниці протоколів зберігання між системами. У цьому вся його суть, в цьому немає нічого розумного. Зберігання в 10 разів кількості накладних витрат за певну кількість даних просто говорить про те, що ви неохайний розробник, який не продумав справи і не може бути налаштований на обробку даних, які ви вживаєте, у розумний, ефективний, швидкий формат запитів. Перестаньте наполягати на зусиллях на оперативній підтримці, і ДУМАЙТЕ про те, як можна краще обробляти дані після вас " я отримав це був би мій дзвінок. Немає захисту для зберігання даних як XML після їх отримання, оскільки він виконував своє призначення.