Это хорошая идея для создания XML API на основе для XML в SQL Server 2005? - PullRequest
1 голос
/ 26 февраля 2010

Один из моих коллег собирается создавать API непосредственно из базы данных. Он хочет вернуть xml для запросов. Это действительно хорошая идея?

Мы должны создать API для наших партнеров, и мы ищем хороший архитектурный подход. У нас есть несколько миллионов продуктов, обзоров и так далее.

Некоторые партнеры будут брать 1000 продуктов, другие хотели бы скопировать почти всю базу данных. Мы должны ограничить доступ к некоторым полям, например, один партнер увидит productDescription, другие только id и productName. Иногда мы хотим возвращать только информацию о категориях в ответе xml, иногда мы хотим включить 100 продуктов для каждой возвращаемой категории.

Один из программистов форсирует решение, основанное почти только на mssql 2005 для xml auto. Он хочет построить запрос в приложении, отправить его на сервер и затем вернуть xml партнеру. Без кеширования внутри приложения.

Это хорошая идея для ралли?

Ответы [ 4 ]

2 голосов
/ 26 февраля 2010

Я использовал эту технику для определенного веб-приложения. У меня смешанные чувства по поводу этого подхода.

Одним из преимуществ является то, что это действительно удобно для простых требований. Другим преимуществом является то, что действительно легко преобразовать изменение схемы базы данных в изменение формата XML, поскольку все в одном месте.

Я обнаружил, что есть и минусы. Когда ваш целевой XML становится более сложным, имеет больше вложенных структур, тогда это решение может быстро выйти из-под контроля. Рассмотрим для примера это (взято из http://msdn.microsoft.com/en-us/library/ms345137(SQL.90).aspx#forxml2k5_topic5):

SELECT CustomerID as "CustomerID",
  (SELECT OrderID as "OrderID"
   FROM Orders "Order"
   WHERE "Order".CustomerID = Customer.CustomerID
   FOR XML AUTO, TYPE),
  (SELECT DISTINCT LastName as "LastName"
   FROM Employees Employee
   JOIN Orders "Order" ON "Order".EmployeeID = Employee.EmployeeID
   WHERE Customer.CustomerID = "Order".CustomerID
   FOR XML AUTO, TYPE)
FROM Customers Customer
FOR XML AUTO, TYPE

По сути, вы видите, что начинаете писать SQL, чтобы отразить структуру вывода XML. И если вы думаете об этом, это плохо - вы смешиваете логику поиска данных с логикой представления - тот факт, что представление в этом случае представление в формате обмена данными, на самом деле не изменить тот факт, что вы смешиваете две разные вещи, делая их обе сложнее.

Например, вполне возможно, что требования к точной структуре XML изменяются со временем, тогда как фактические требования к связанным данным остаются неизменными. Тогда вы будете переписывать запросы, даже если в том наборе данных, который вы уже получаете, нет ничего плохого. Это кодовый запах, если вы спросите меня.

Еще одним соображением является настройка производительности / запросов. Я не могу сказать, что провел много сравнительных тестов для этих типов запросов, но я обычно избегал бы подобных подзапросов, как только смогу ... и теперь, просто из-за этого синтаксического сахара, я бы внезапно выбросил это из-за удобства генерировать XML без посредников? Я не думаю, что это хорошая идея.

Короче говоря, я бы использовал эту технику, если бы мог значительно упростить вещи. Но если бы я мог ожидать, что мне все равно понадобится язык-посредник для генерации всех необходимых мне XML-структур, я бы решил вообще не использовать эту технику. Если вы собираетесь генерировать XML, делайте все это в одном месте, не кладите некоторые в запрос, а некоторые в вашу программу, потому что это станет кошмаром для управления изменениями и их обслуживания.

1 голос
/ 28 февраля 2010

В общем, я не вижу ничего плохого в раскрытии информации, хранящейся в СУБД, через API «только для чтения», который устанавливает ограничения доступа на основе привилегий пользователя. Поскольку ваше приложение строит запросы, вы можете выставить любые подходящие имена для ваших существительных (таблиц) и атрибутов (столбцов) в пользовательском API.

Большинство БД могут кешировать запросы (и хотя я вообще не знаю SQL-сервер, я полагаю, что он может это делать), и главное преимущество не кеширования «нисходящего потока» в приложении - простота - данные, возвращаемые для каждого API Вызов будет актуальным, без какой-либо сложности выяснения, когда обновлять «нисходящий» кеш. Вы всегда можете добавить кеширование позже - когда вы уверены, что все работает правильно и , вам действительно нужно повышение производительности.

Что касается синхронизации запросов и XML - если вы просто сбрасываете записи данных, сгенерированные из одной таблицы, то здесь проблем не возникает. Это правда, что когда вы начнете комбинировать информацию из нескольких таблиц на внутреннем сервере, будет сложнее генерировать записи данных с помощью одного запроса, но исправление этого с помощью промежуточных структур данных в приложении веб-сервера является подходом, который (как правило) плохо масштабируется. по мере роста таблиц - зачастую лучше помещать данные, которые необходимо представить, в один запрос / вызов API в представление базы данных.

Если ваш XML разработан таким образом, что вам нужно загрузить все данные в память и вычислить статистику (например, для отображения в атрибутах элемента XML) до начала рендеринга, тогда у вас будут проблемы с масштабируемостью независимо от того, что ты делаешь. Поэтому постарайтесь с самого начала избегать проектирования своего XML.

Обратите также внимание, что XML часто можно «нормализовать» (как и таблицы БД), используя внутренние ссылки и элементы «GLOSSARY», которые выделяют повторяющуюся информацию. Это уменьшает размер сгенерированного XML, и, отображая элемент GLOSSARY в конце документа XML (возможно, с информацией, извлеченной из последующего запроса SQL), вы можете избежать необходимости хранить много данных в памяти веб-сервера при обслуживании вызова API. .

1 голос
/ 26 февраля 2010

Это плохая идея. SQL Server может возвращать данные только через протокол TDS, то есть это может быть только набор результатов (строки). Возвращение XML означает, что вы по-прежнему возвращаете набор строк , но набор данных SQL отформатирован как XML. Но в конечном итоге вам все еще нужен клиент протокола TDS (т. Е. SqlClient, OleDB, ODBC, JDBC и т. Д.). Вам все еще нужно иметь дело со строками, столбцами и ошибками T-SQL. Вы возвращаете столбец , содержащий данные XML, а не ответ XML.

Итак, если ваш клиент должен быть клиент базы данных , какое преимущество дает XML? Кроме того, что вы потеряли всю информацию метаданных результата схемы в процессе ...

Кроме того, учтите, что хранимые процедуры - это API для доступа к всему , включая задачи SSIS, задания по обслуживанию и ETL, другие приложения, развернутые в базе данных и т. Д. Если все будет представлено на этом уровне как XML, быть беспорядком Две хранимые процедуры из связанных приложений, оба в одном экземпляре, обмениваются вызовами через for-xml и затем xpath-squery? Зачем? Имейте в виду, ваша база данных переживет все приложения, которые вы имеете в виду сегодня.

Я понимаю XML как хороший формат для обмена данными между веб-сервисами. Но не между базой данных и клиентом. Таким образом, ответ таков: ваши партнеры должны видеть XML, но из вашего слоя веб-службы , а не из вашей базы данных .

0 голосов
/ 26 февраля 2010

Это зависит от того, кто будет использовать этот API. Если этот API будет использоваться большим количеством разных языков, то да, возможно, имеет смысл выставлять возвращаемые данные в формате XML, поскольку практически все в состоянии разобрать Xml.

Если, с другой стороны, API будет в основном использоваться только одним языком (например, C # / .Net), то вы будете намного лучше писать API на этом языке и напрямую предоставлять данные в формат, родной для этого языка - предоставление результатов на основе Xml приведет к ненужной генерации и последующему анализу Xml.

Лично я, вероятно, выбрал бы смешанный подход - выбрать подходящий обычно используемый язык (для клиентов этого API) для написания API, а затем, кроме того, предоставить дополнительный API на основе xml, если он необходимо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...