Моделирование: Xml против реляционной базы данных

Question

Мне интересно, есть ли лучшие практики для решения, когда следует моделировать систему с использованием XML, и когда она должна моделироваться с использованием реляционной базы данных (я знаю, что вы можете хранить XML в базе данных, но между ними существует огромная разница моделирование системы с использованием нормализованных таблиц БД и моделирование системы с использованием XML-схемы). Для конкретности, скажем, вы моделировали упражнения в тренажерном зале. «Жим лежа» - это на самом деле семейство упражнений, а не единственное упражнение. Вы можете лечь на скамейку или мяч. Вы можете заставить себя вернуться или позволить обмануть. Вы можете использовать гантели, штанги, кабели или универсальный станок. Если вы используете гантели, вы можете чередовать руки или толкать одновременно. Вы можете иметь наклонную, наклонную или плоскую поверхность. Я думаю, что из-за сложности (и возможной сложности, о которой мне еще только предстоит подумать), это лучше всего смоделировать с помощью xml. Это хорошая оценка? Какие еще важные факторы следует учитывать?

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

Answer 1

В 1960-х годах были изобретены / разработаны / разработаны системы управления данными, основанные на идее, что данные могут быть организованы иерархически. IMS является одним из них. Ошибки / недостатки / недостатки этих систем сразу же стали очевидными для любого, кто интенсивно их использует (например, они приводят к «смещению запросов»: в иерархических системах часто легко запрашивать, какие контракты существуют для данного клиента, и в то же время практически невозможно запросить, какие клиенты участвуют в данном договоре).

Все эти недостатки в конечном итоге привели к изобретению реляционной модели.

Так что, если вы хотите знать, подходит ли XML в качестве решения ЛЮБОЙ ПРОБЛЕМЫ УПРАВЛЕНИЯ ДАННЫМИ, ЧТОБЫ ТАКОЕ, спросите себя: «Является ли XML иерархическим по своей природе или нет?».

Успех XML на рынке только подтверждает правильность наблюдения, что «те, кто не знает истории, обречены ее повторять».

Answer 2

Ваш пример упражнений можно смоделировать разными способами. Для некоторого опыта и мудрости в вопросе о том, когда иерархическая модель XML демонстрирует преимущество, прочитайте Рон Барретт:

http://www.rpbourret.com/xml/XMLAndDatabases.htm

Существуют случаи, когда собственные xml-базы данных демонстрируют огромные преимущества RDB, когда контент для хранения является полуструктурированным. @ Не говорите, что проще и безопаснее хранить данные о клиенте-контракте-клиенте в RDB - но что происходит, когда вам также нужно хранить контракт?

RDF контрастирует как с реляционными моделями, так и с XML-моделями. RDF разработан для представления данных в "открытом мире", в котором вы никогда не сможете быть уверены, что знаете все в то время, когда вам нужно вычислить. Тот факт, что RDF может быть выражен в xml, удобен, но случайен. У него есть и другие выражения.

Читайте также в EMC XML Technologies и MarkLogic.

Answer 3

Ваш пример упражнений хороший, но я думаю, что вы пришли к неверному выводу.

Я думаю, что из-за сложность (и возможная сложность что мне еще придумать) что это лучше всего смоделировать с помощью XML.

Я думаю, что этот вывод основан на ошибочном предположении, что XML обеспечивает большую гибкость моделирования, чем реляционная модель. На самом деле (как умело описывает Эрвин Смут), реляционная модель по своей природе более гибкая, чем XML, поскольку XML строго иерархичен, тогда как реляционная модель допускает отношения «многие ко многим» произвольной сложности.

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

Answer 4

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

Если вам приходится иметь дело с многопользовательской средой, вы все равно можете использовать XML, но вам потребуется создать сложный бизнес-уровень вокруг него, отслеживая изменения всех пользователей и в основном добавляя множество многопользовательских функций, которые стандартная СУБД предлагает в качестве стандарта. Если у вас много данных, есть риск, что ваш XML-файл станет слишком большим. Стандарт XML немного раздут, и если вам придется работать с файлами XML объемом 500 МБ каждый, надеюсь, у вас будет много-много терпения.

Есть, конечно, другие альтернативы. Однажды я создал простой веб-сканер, который будет загружать веб-страницу, извлекать все URL-адреса в ней и затем повторять это действие для каждого URL-адреса. В нем использовалось около 20 потоков, которые все загружали страницы, и количество URL-адресов вырастет в миллионы. Я хотел избежать загрузки одного URL-адреса дважды, поэтому мне пришлось отфильтровывать дубликаты. Использование XML было бы кошмаром, учитывая объем данных. Использование базы данных было излишним, так как все, что мне было нужно, - это одна таблица с одним полем: URL. Поэтому я написал специальный алгоритм хеширования и создал свое собственное решение на основе файловых хеш-таблиц. Это было действительно быстро, проверяя несколько тысяч URL-адресов в секунду, если не нужно было загружать эти страницы ...

В ситуациях, подобных этому, я бы начал с создания простой схемы XML с использованием некоторого инструмента моделирования для XML. (Altova XMLSpy хорош в этом.) Когда я думаю, что мои данные хорошо вписались бы в этот XSD, я начинаю создавать базу данных, где каждый элемент будет преобразован в таблицу. В результате у меня была бы хорошая реляционная база данных плюс некоторое определение формата XML, который можно использовать для импорта / экспорта тех же данных в / из базы данных.

Answer 5

Как насчет "ничего из вышеперечисленного"?

Сначала я бы смоделировал домен, используя инструмент концептуального моделирования, такой как NORMA . Это позволит вам сконцентрироваться на модели, пока вы не закончите. На этом этапе NORMA может генерировать DDL для нескольких популярных баз данных, а также схему XML.