Xml і бази даних довіртеся своїй інтуїції

Рішення, рішення

Одна з найскладніших завдань, що стоять при виборі технології - це формування неупередженої картини про всі слабкі і сильні сторони обраного продукту. Це підтвердить будь-який, хто, намагаючись дістатися до технічної суті, опинявся угрузлим в "глянсовому пишноті" "Білих паперів".

Саме тому спільноти передових користувачів, як, наприклад, XML-DEV, володіють незаперечною перевагою в цьому питанні: вони надають місце для об'єктивного обговорення і зіставлення достоїнств різних технологій. Тоді, озброївшись фактами і знаючи всі "за і проти", рішучий розробник зможе прийняти більш обгрунтоване рішення. Процес прийняття рішення можна поліпшити - якщо інші члени спільноти побажають поділитися своїми висновками з іншими користувачами.

Так, Брайен Меджік (Brian Magick), зіткнувшись з необхідністю вибрати відповідну технологію баз даних для XML-додатки, звернувся до товариства XML-DEV з питанням: чи не намагався хтось зібрати відповідну "дерево рішень" ( "decision tree"). Пізніше він конкретизував своє завдання.

"Я просто хотів в принципі зрозуміти, коли переходити до XML і створювати додатки з базами даних, а коли - не переходити і зберігати дані в реляційних базах. Чому одні вважають за краще тримати дані в реляционном форматі, а не перетворювати їх в XML і розробити XML- базу. що стосується нових додатків, що повинен враховувати розробник при ухваленні рішення піти традиційним шляхом, замість того, щоб скористатися новою "крутий" XML-технологією? На жаль, вибравши XML-базу даних, багато розробників захочуть використовувати це нове інструменту ьное засіб, хоча воно, насправді, призначене не для всіх нових баз даних / додатків ".

Однак, ми повинні вас про дещо попередити. По-перше, ці міркування належать спільноті XML-DEV; ймовірно, є й інші, що вимагають розгляду, як, наприклад, функціональні або бюджетні рамки, які можуть так чи інакше вплинути на Ваш вибір. По-друге, частина рекомендацій ґрунтується на поточний стан ринку баз даних; у міру її розвитку, можливо, інші ідеї стануть більш важливими, а нинішні фактори будуть менш актуальні. По-третє, в поле зору не потрапили спеціальні продукти. Не всі системи управління базами даних однакові, так що, безумовно, на кожне правило буде своє виключення. Як троянди можуть рости на гної, так і продукти з гарною репутацією можуть приховувати будь-що, скажімо, бридке.

Вибираючи бази даних

Здебільшого дані

"Я бачив опису типу шаблону документа з сотнями елементів, і визначення прийнятного перетворення від них до бази даних - це явно нетривіальне завдання, особливо коли багато елементів є обгортками, що не відображають реальну структуру в базі даних". (Рональд Бурре)

Здебільшого документи

Якщо те, що ви зберігаєте, в значній мірі - документи, а не більшою частиною дані. тоді NXD може бути кращим рішенням. Однак, це буде залежати від типу запитів, який вам потрібно робити до цих даних. Деякі документоорієнтовані схеми мають очевидні метадані. які спростять реляционное перетворення. Точно перетворити змішаний контент в реляційну схему важко, а документоорієнтованих XML часто має непостійну структуру.

". Змішаний контент погано перетвориться за допомогою об'єктно-реляційного перетворення. (Я не збираюся вдаватися в подробиці. Більш детально про це написано в розділі 3.3 і 3.4," Перетворення описів шаблону документа до баз даних "[Mapping DTDs to Databases]. (Рональд Бурре)

"Набагато легше підтримувати сукупність XML-документів, використовуючи XML-базу даних, ніж перетворювати ці документи в реляційну базу даних або навіть зберігати їх як" блоб ". (Том Бредфорд (Tom Bradford))

змінюється структура

Реляційні бази цих надзвичайно гарні для зберігання високо структурованої інформації та не дуже гарні для управління полуструктурированного даними. Документоорієнтованих XML зазвичай має непостійну структуру для обліку гнучкості, характерної для звичайної прози. Однак, не всі напівструктуровані дані є документоорієнтованих (наприклад, списки матеріалів). Хоча полуструктурированного інформацію можна перетворити в реляційну модель, можливі накладні витрати на виконання, особливо при виконанні запитів. NXD або XED з можливістю індексації XML-даних чудово підходять для такого типу інформації.

"Полуструктурірованние дані - це дані, які володіють деякою структурою, але не є жорстко структурованими. Прикладом напівструктурованих даних може служити запис в медичній карті. Так, для одного пацієнта вона може містити перелік щеплень, для іншого - показники зростання і ваги, для третього - операції, який йому зробили. Інший приклад напівструктурованих даних - юридичні документи, генеалогічні записи.

Полуструктурірованние дані складно зберігати в реляційної базі даних, оскільки в цьому випадку у вас або багато різних таблиць (що означає численні з'єднання і тривалий час пошуку), або єдина таблиця з безліччю порожніх колонок. Полуструктурірованние дані дуже легко зберігати як XML, і вони чудово підходять для XML-бази даних "(Рональд Бурре)

"Одне з головних достоїнств (що відносяться даних) моделі даних XML полягає в можливості обробляти напівструктуровані дані. У той час як реляційні СУБД не можуть досить добре обробляти напівструктуровані дані." (Ден Уейнреб (Dan Weinreb))

жорстка структура

Якщо ви зберігаєте XML, схема якого має фіксовану структуру (тобто практично або взагалі не використовуються змішаний контент або моделі з рекурсивним контентом), тоді реляційна база даних, можливо, більш прийнятне рішення.

". Реляційні бази даних, як правило, кращий спосіб зберігання високо структурованих даних. Хоча, більшість XML-постачальників, з якими я звертався, говорять те ж саме, ніхто з них не може сказати точно, де можна провести кордон". (Рональд Бурре)

очевидні метадані

Зазвичай, щоб представити структуру заголовок-тіло (head-body structure), в XML-схемах використовується проектний шаблони, які метадані включаються в заголовок документа, а контент - в тіло. У цьому випадку часто необхідно індексувати саме метадані в заголовку і звертатися до них із запитом. Цей шаблон досить легко перетворити в реляційну базу даних або XED, оскільки, зокрема, метадані рідко використовують змішаний контент спеціально. Якщо ваша (і) схема (и) відповідають цьому шаблону, тоді цей спосіб зберігання - відповідне рішення. Можна використовувати можливість підтримки XML, якщо необхідно маніпулювати контентом тіла або звертатися до нього з запитом. Однак, якщо вам потрібно робити складнізапити до контенту вашого документа, тоді, можливо, краще вибрати XML-базу банних.

складні питання

При розгляді технології бази даних дуже важливо врахувати, яким чином буде відбуватися доступ до даних. Якщо у вас орієнтований на дані XML. ймовірно, РСУБД - кращий вибір, як і для XML-документів, які мають очевидні метадані. Однак, як тільки вам буде потрібно виконати пошук по всьому тексту або маніпулювати моделлю рекурсивного контенту, NXD або XED з відповідним мовою XML-запитів здаються більш прийнятним рішенням.

Хоча, найбільш популярною мовою запитів - вважається XPath (як правило, з розширеннями для запитів до багатьох документів), підтримуються і багато інших мов запитів (всі вони фірмові). Це справедливо як щодо реляційних баз даних, що підтримують XML, так і XML-баз даних.

На це є свої причини - XPath в достатній мірі розвинений, щоб виконати всі запити, які необхідні користувачу, а XQuery поки ще не закінчений. У мене є підозра, що, коли роботи по над XQuery будуть завершені, з'явиться безліч його реалізацій ". (Рональд Бурре)

Загальна сховище

Дуже часто трапляється так, що ви маєте в своєму розпорядженні готовим сховищем даних (в яке зроблені відповідні капіталовкладення), дані якого ви збираєтеся використовувати разом зі своїми XML-даними. В цьому випадку, можливо, буде потрібно розглянути переваги інтеграції в масштабі підприємства за допомогою NXD. Крім того, можуть виникнути питання цілісності даних. Крім цього, можливість використання даних спільно з додатками, які не підтримують XML, відноситься до основних вимог; найчастіше це справедливо по відношенню до орієнтованого на дані XML, і така ситуація зазвичай виникає при додаванні XML-відображення в готову базу даних або репозиторій. З огляду на це, РСУБД або XED - це ідеальний вибір.

"Здебільшого ви зможете обмежиться реляційної базою даних, особливо якщо більшості додатків, які отримують з неї дані, не потрібно маніпулювати даними або переглядати їх як XML. У такій ситуації повністю досить програмного забезпечення проміжного шару XML або можливостей перетворення, які підтримує більшість РСУБД" . (Том Бредфорд)

"Дані в реляційної базі даних, що підтримує XML, доступні як для XML, так і не XML-додатків - що, за рідкісним винятком, не можна сказати про XML-баз даних. Тобто майже жодна XML-база даних не підтримує можливість повернення даних в форматі, відмінному від XML ". (Рональд Бурре)

"Інше питання - можуть ледве не XML-додатки використовувати дані, не розуміючи XML. Так - якщо XML перетворений в таблиці, і немає - якщо XML зберігається у BLOB". (Рональд Бурре)

поточні капіталовкладення

Як і при оцінці будь-якої технології, необхідно враховувати поточні капіталовкладення; неприпустимо принижувати інвестиції в розробку певних характеристик. XML-база даних не потрібно для багатьох додатків, існуючі технології вже можуть забезпечити необхідну функціональність. XML-властивості будуть включені в бази даних подібно до того, як були додані властивості об'єктів. Прийняти XED або навіть NXD може бути також просто, як залишатися на поточному платформі та починати використовувати нову функціональність, як тільки вона з'являється. Цей підхід прийнятний в тому випадку, якщо ви додаєте підтримку XML в існуючу програму з кінцевою метою у вигляді загального сховищ.

"." # 9496; Заради чого люди, що використовують РСУБД для зберігання своїх класичних ключових корпоративних даних, повинні переходити до XML, як моделі даних? Врешті-решт, реляційна модель вельми добре задовольняє їхні потреби. Ніхто ще не повідомляв про кризу, спричиненим недоліками реляційної поділи. Далі, в таких системах перехід від реляційної моделі даних до будь-якої іншої - ризикована справа, яка зажадає маси зусиль. Для цих баз даних була створена велика суперструктура: генератори звітів, звіти, написані для цих генераторів, всілякі інструментальні засоби і розширення, пропоновані постачальниками, той факт, що величезна армія людей була вихована в дусі третьої звичайної форми, мови SQL, і так далі і таке інше.

. Досить просто уявити, як XML-СУБД намагаються витіснити реляційні СУБД, намагаються взяти над ними вгору і замінити їх, і ви зрозумієте, як все це несерйозно ". (Ден Уейнреб)

Численні схеми або навіть відсутність схеми

Якщо вам необхідно зберігати документи, відповідні численним схемам або у випадку відсутності схеми (мається на увазі, що вам необхідно мати справу з полуструктурированного даними), зусилля, необхідні для того, щоб розробити реляционное перетворення для окремих типів документів (особливо тих, які будуть задовольняти всім вимогам до запиту), можуть виявитися надмірно великими. Якщо ж схеми безперервно розвиваються, особливо якщо ви не можете це контролювати, дана проблема лише поглиблюється. В такому випадку NXD з можливістю гнучкого зберігання - відмінний вибір.

"У разі численних джерел даних може бути дуже вигідно використовувати XML для опису структурованих даних. Якщо ви не повністю контролюєте" схему "або форму інформації, яка надходить з різних серверів. Використання XML-бази даних, незалежної від схеми зменшить час на розробку і послабить "тягар" майбутнього супроводу: вам буде не потрібно створювати і перетворювати [ряд] реляційних схем, щоб представити всі свої різні. джерела, також від вас не буде потрібно підтримувати цю схему в разі змін ". (Боб Лорд (Bob Lord))

повний обхід

При перетворенні XML-документа в реляційну базу даних (або навіть XED, якщо ви не використовуєте BLOB для зберігання всього документа) практично неминуче, що деяка частина інформації про цей документ буде втрачена. XML-бази даних не «грішать" цим. Отже, якщо вам необхідно, щоб дані зберігали свою первинну структуру при зберіганні та вилученні, NDX - єдине рішення. Повний обхід, ймовірно, буде основною вимогою в процесі виконання інтеграції в масштабі підприємства. потрібно зберігати журнали реєстрації повідомлень, якими обмінюються системи.

Цілісність даних

Цілісність посилальних даних лежить в основі реляційної моделі. Однак, XML-положення про цілісність визначено не так добре, хоча зв'язують технології та існують, часто не ясно, як краще їх використовувати, і, ймовірно, буде потрібно код додатка для підтримки цілісності. Якщо це є жорсткою вимогою, краще вибрати реляційну базу даних або базу, яка підтримує XML.

Інтеграція в масштабі підприємства

Найбільш загальний спосіб застосування XML, особливо орієнтованого на дані. - це використання його як засобу інтеграції або обміну даними між додатками підприємства всередині або поза брандмауером. За останні кілька років спостерігався розвиток програмного забезпечення проміжного шару, а з урахуванням розширення використання XML для таких типів повідомлень, NXD може претендувати на участь засоби управління потоком повідомлень. Це особливо вірно, коли повідомлення не будуть негайно використовуватися (і їх не потрібно поміщати в кеш), їх потрібно реєструвати з юридичних причин, або ж вони зажадають підтримки для транзакцій.

XML-бази даних здаються відмінним способом інтегрування даних з різних обробників (backends), і я думаю, що майбутнє за XML-базами даних - вони зроблять це прозоро і реверсивно. (Деякі роблять це вже сьогодні.) У реляційних баз даних в цьому питанні можуть бути складності, оскільки результатом інтеграції даних з різних джерел, ймовірно, є напівструктуровані, а не структуровані дані ". (Рональд Бурре)

"Я повністю згоден з тим, що інтегрування даних з різних обробників - одна із сильних сторін XML-СУБД, а здатність обробляти напівструктуровані дані - їх основне право.

Деякі XML-СУБД також прекрасно підходять на роль постійного транзакційного розподіленого кешу середнього шару ". (Ден Уейнреб)

"Будь то фізичний XML або віртуальне уявлення, інтеграція даних - одна з основних причин використання XML, а забезпечення функціональності бази даних для XML-вистави - один з незаперечних аргументів на користь XML-бази даних". (Джонатан Роуб (Jonathan Robie)

". Приховайте неймовірний безлад, що панує в" бек-офісі ", за XML- поданням, кешуватися в XML-СУБД, так щоб інші програми не знали або не турбувалися про" шаманство за сценою ".

Безсумнівно, наведений вище список можна розширити і привести інші доводи, які могли б допомогти зіставити одне міркування з іншим. Сподіваюся, що це виявиться хорошою відправною точкою для подальшого обговорення.