PapperВсем привет!
Я хочу использовать формат XML для повседневного хранения и работы с данными.
Вопросы следующие:
1. Чем XML лучше СУБД(access, mySQL, Oracle, MSSQL, postgres и т.д.)?
2. Насколько в нем удобнее работать по сравнению с СУБД?
3. Насколько удобнее интерфейс с XML из VisulStudio 2005, чем существующие интерфейсы с другими СУБД?
4. Насколько лучше XML чем реляционные базы данных?
Пожалуйста выскажите своё мнение по данным вопросам.

XML в целом это не реляционная я иерархическая БД, если его можно так назвать. Неудобнее тем, что XML нужно полностью загружать в память и работать в памяти с ним, изредка сбрасывая на диск (SAX-парсеры не рассматриваем).

Лично с xml работал с Delphi(NativeXML) - отличная вещь, где нельзя лечь в первую нормальную форму, а требуется иерархия.

Можно комбинировать xml+РБД, в xml-данных держать иерархию, типа документов, в БД списки и отношения.

AlexTheRaven
Реляционные структуры укладываются в XML, равно как иерархические - в РБД.

Только нужно говорить один ньюанс:

В классическую РБД лягут только те иерархические струтктуры которые соответствуют первой нормальной форме.

Хотя преимущества XML и РБД содержать многомерные СУБД типа Cashe, но в остальном там одни недостатки...


Ньюанс:
- "Василий Иваныч, а что такое НЮАНС?"
- "Снимай, Петька, штаны и вставай раком!".
Ну, снял Петька штаны, встал раком - а Василий Иваныч ррраз! йух ему в жопу по самые помидоры!
- "Чувствуешь, Петька: у тебя - йух в жопе? Так ведь и у меня - йух в жопе. Но между нами - огромная разница. Это, Петька, и есть - НЮАНС!"

Papper
Спасибо. А вообще можете назвать основные приимущества ныне популярных СУБД?

То что каждая домохозяйка может установить свой сервер СУБД(тот же оракл) и наваять под него кастомизированную ERP в том же Access/Excel.

Тоесть кроме простоты со времен Кодд-а особо ничего не изменилось. Тот же самый Ansi SQL в каждом из серверов слегка опиленный и обточенный под задачи данного сервера.

Papper soft Papper
Спасибо. А вообще можете назвать основные приимущества ныне популярных СУБД?

То что каждая домохозяйка может установить свой сервер СУБД(тот же оракл) и наваять под него кастомизированную ERP в том же Access/Excel.

Тоесть кроме простоты со времен Кодд-а особо ничего не изменилось. Тот же самый Ansi SQL в каждом из серверов слегка опиленный и обточенный под задачи данного сервера.

Это то понятно, но все равно охота использовать последние наработки.
Тот же Access отличается просто непонятной идеологией отличной от любой нормальной.
И вооще, я за то что бы максимум действий делала сама СУБД(подготовка, обсчет, архивирование и т.п.), а на сторону клиента только вывод результата работы СУБД.
Так вот какие СУБД дают большую свободу, а конкретнее какая из бесплатных СУБД? :)

Я же вам говорю ВСЕ. Еще ни с одной СУБД не приходилось ничего делать кроме пары кликов мышкой, чтобы ее установить в БАЗОВОМ РЕЖИМЕ.

А Компонента TERP для Delphi пока еще не придумали :( чтобы ее можно было кинуть на форму и чтобы она в SAP сама собой развернулась.

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

По поводу 1 - неклассические это постреляционные СУБД . Определение ищите сами.

По поводу второго - имеем набор объектов каждый из которых може агрегировать определённое множество объектов-свойств разных типов. Если ложить в БД то на каждый тип объекта стоит заводить одну табличку или будет разнеженность (хотя через задний проход эту проблему можно решить если все объекты пихать как блобы или табличку с 20000 столбцов и все данные свойств преобразовывать в стринги).

А если у нас типов объектов около 100000, то что вам Oracle скажет на наличие в базе 100000 таблиц?

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


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



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


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



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

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

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