Papper<...>
1. Чем XML лучше СУБД(access, mySQL, Oracle, MSSQL, postgres и т.д.)?

XML корректно сравнивать, например, с ini, csv, dbf, mdb и т.д. С СУБД следует сравнивать конкретную библиотеку для работы с XML. С одной стороны, формат XML вроде бы текстовый, user friendly, что облегчает тестирование и использование. С другой стороны, обычно программисты реализуют такой "формально правильный" XML, который совершенно не user friendly, и большая часть его преимуществ сразу же теряется.

Papper
2. Насколько в нем удобнее работать по сравнению с СУБД?

Кто к чему привык. Если знаете язык запросов к СУБД - ни насколько не удобнее.

Papper
4. Насколько лучше XML чем реляционные базы данных?
Реляционные структуры укладываются в XML, равно как иерархические - в РБД. А структуры сравнивать, целесообразность их применения зависит от предметной области.

В общем, если данных мало (десятки тыс. записей, общ. объём до мегабайта), и не предусмотрен полноценный UI для их ведения - целесообразно использовать XML.

Тут есть ещё такая особенность: библиотеки для работы с dbf и mdb создавались давно, когда компьютеры были маломощными, поэтому "вылизаны" они замечательно, не одного лишнего байта или цикла процессора не скушают, ошибки в них давно все исправлены, а вот "прожорливость" и "глючность" XML-библиотек - притча во языцех.

soft<...>
В классическую РБД лягут только те иерархические струтктуры которые соответствуют первой нормальной форме.<...>
1) Чем классическая РБД отличается от неклассической?
2) Приведите пример иерархической структуры, которая НЕ соответствует 1-й нормальной форме

soft<...>
неклассические это постреляционные СУБД . <...>
Маркетинговый термин без чёткого определения. Вам ещё и не такое продадут.

soft
По поводу второго - имеем набор объектов каждый из которых може агрегировать определённое множество объектов-свойств разных типов. Если ложить в БД то на каждый тип объекта стоит заводить одну табличку или будет разнеженность (хотя через задний проход эту проблему можно решить если все объекты пихать как блобы или табличку с 20000 столбцов и все данные свойств преобразовывать в стринги).
Действительно, при сохранении экземпляров в сериализованной форме, нарушается 1-й НФ. Но это всего лишь одно из возможных решений. Для укладывания объектов в БД есть "паттерны" ROT и EAV, которые ничего не нарушают.
Класс с 20'000 свойств - IMHO не имеет смысла. 20 свойств - уже много.

soft
А если у нас типов объектов около 100000, то что вам Oracle скажет на наличие в базе 100000 таблиц?
В БД не нужно хранить архитектурные излишества - только классы, хранящие информацию о бизнес-сущностях. Больше неск. тысяч таких классов может быть только в САПР. Но для САПР поиск и параллельный доступ на RW сотни пользователей к каждой шестерёнке на чертеже особенно и не важен, поэтому XML там замечательно применим.

В остальных случаях РБД замечательно справляется со всеми задачами хранения информации.

soft
Нет, в идеале там каждое поле в записи может выступать новой таблицей. В 95% случаях это не нужно, но эти 5% случаев часто дают 95% процентов привлекательности продукта в специализированных областях.

Хорошая фича, позволяющая без особых ухищрений нарушать 1 НФ , а потом героически бороться со сложностью и кривизной.

AlexTheRaven
Тоесть если коиенту нужно сохранять документ с 300 полями, то вы ему скажете, что это нестандартно, много и никому не нужно? Так он вам и ответ - отстой этот ваш Oracle и ораклоиды все ламеры... И будет прав.

Значительная часть "полей" документа - обычно визуализация связи сущности "документ" с другими сущностями - "контрагент", "кол-во товаров", "ответственное лицо" и т.д. Так что 300 - это очень много. В любом случае, не хватает полей (а в большинстве современных СУБД их может быть до 65 тыс. с чем-то) - есть паттерн EAV.

AlexTheRaven<...>
А давайте заменим остальных случаях на старндартных случаях.
Хорошо, в остальных стандартных случаях, к коим относится только САПР.
Ещё раз: РСУБД плохо справлялись с данными в САПР. Поэтому для САПР стали придумывать ООСУБД. Не XML.

А XML - это всего лишь правило, накладываемое на хранение информации в текстовых файлах. Раньше все приложения писали информацию в текстовые файлы, как им заблагорассудится. Теперь они делают то же самое, только модно, чтобы текстовые файлы подчинялись правилам XML. Действительно, разборка стала единообразнее, появилась возможность увеличить повторное использование.

Применение XML не избавит Вас от необходимости решать проблемы целостности, поиска и многопользовательского доступа. Блокировка всего файла XML - блокировка на уровне БД, к-рую СУБД перестали делать лет 30 назад. То же самое и с поиском "полным сканированием".

AlexTheRaven
Тогда я даже с вами соглашусь. РБД это как 1С, только лучше, где все стандартное, то все хорошо, если чуть в сторону от классических схем, то все через жжжжж..... ну вы поняли.
Классические схемы потому и классические, что к ним много раз приходили от "неклассических". Они тоже могут быть кривыми и неудобными, но ничего лучше пока не придумали.