Коли я повинен використовувати тип даних XML у SQL сервері?

Коли я повинен використовувати тип даних XML у Microsoft SQL Server?

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

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

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

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

Просто моя думка, звичайно :)

Я стикався лише з декількома сценаріями, коли я активно продовжував би використовувати тип даних XML у SQL Server. Це вгорі моєї голови, щоб, як мінімум, до найцікавішого:

• Зберігання / архівування відповідей XML, генерованих іншими програмами
  • Наприклад, ми використовуємо Framework Integration Application Framework (AIF) для зв'язку між користувацьким додатком Silverlight та Dynamics AX. Ми зберігаємо вхідні та вихідні повідомлення в базі даних, щоб допомогти у усуненні несправностей у зв’язку між цими програмами
  • Оскільки тип поля - це XML, а не загальний тип рядка (тобто VARCHAR), ми можемо використовувати XQuery для конкретного запиту на повідомлення, що відповідають певним критеріям. Це було б набагато складніше, якщо просте узгодження рядка LIKE
• Кешування / збереження складеного повідомлення відповіді
  • Оновіть поле XML за допомогою тригера або коду програми, який би імітував обчислений стовпець
  • Замість того, щоб постійно відновлювати відповідь XML на додаток для виклику, ви матимете накладні витрати лише тоді, коли рядок буде переведено, а не при кожному виклику
  • Це найкраще працює, коли SELECT набагато частіше, ніж ОНОВЛЕННЯ / ВСТАВКА, що, як правило, відповідає більшості програм
• Зберігання декількох значень в одному полі
  • Однією з практик, яку я бачив, є використання типу даних XML для зберігання колекції значень в одному полі
  • Одна перевага полягає в тому, що вам не потрібно розробляти додатковий набір таблиць для простого магазину ключів / цінностей
  • Недоліком цього є те, що дані не нормалізуються повністю, що робить запит менш очевидним
  • Однак, як було сказано вище, ви можете використовувати XQuery у цьому полі XML для вибору рядків, які відповідають ідентифікованим критеріям, тим самим частково нутралізуючи вплив не повністю нормалізованого.

Все, що говорилося, у 99% часу я абсолютно не потребую поля XML при розробці схеми.

Кілька разів, коли я бачив тип даних XML на SQL-сервері, він в основному використовувався як поле, яке запитувалося так само, як і будь-який інший в базі даних, що може мати дуже погані наслідки для продуктивності, якщо у вас є велика кількість даних . Існує причина, що його називають SQL-сервером, а не XML-сервером. :-) Запити, що відповідають XML, просто не такі швидкі, як звичайний вибір запиту.

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

Я використовував поля типу XML здебільшого для ведення журналів, пов’язаних із веб-службами ASMX або послугами WCF. Ви можете зберегти запит або відповіді.

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

Ось такі сценарії, які приходять в голову негайно, при розгляді того, які умови повинні існувати, щоб дозволити поля Xml на Sql Server:

• двійкові дані, закодовані для обміну, де потрібно кислоти, як контроль над ресурсом
• фрагменти документа, які будуть відновлені в цілому за допомогою динамічної інформації
• Користувач подав документи або фрагменти, які ви хочете ізолювати і принаймні тимчасово зберігати безпосередньо від файлової системи.

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