XML база

[mentanos]

может просто с непривычки об XML такие отзывы?
Если не слишком большая разница в производительности это не страшно для меня, или может быть смотря как это сделать что быстрее может получиться?!
А какие еще огрехи могут быть?

ЗЫ. Помню еще время когда PHP появлялся то все как один гнали на него и хвалили PERL, но сейчас он отошел в сторонку и занимаеться своми делами, а в WEB программирований PHP лидирует.

XML активно продвигаеться сейчас, большие обороты.

ответь сам себе на вопрос: нужна ли мне база, которая будет всегда и страшно тормозить на более-менее крупном наборе данных?

а php вошел в оборот потому, что он более дружественен - его легче освоить, чем perl

 

[dazed]

Нашел интересные мнения:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Я не говорю что хочу использовать только на XML и все тут, я пока лишь только присматриваюсь, в каких случаях лучше XML бд а в каких MySQL.
Спасибо за разъяснения, буду думать.
А с чем связанно что при больших объемах будут сильные тормоза? Из-за того что все в одном файле? И большие это сколько? больше 1 гигабайта?

 

[ConstNW]

используя xml в связке с пхп ты никаких бонусов не получишь.

как и говорится в приведенных тобою статьях: повесишься от дата-майнинга.

 

[Thoth666]

Нашел интересные мнения:

*** скрытое содержание ***

Я не говорю что хочу использовать только на XML и все тут, я пока лишь только присматриваюсь, в каких случаях лучше XML бд а в каких MySQL.
Спасибо за разъяснения, буду думать.
А с чем связанно что при больших объемах будут сильные тормоза? Из-за того что все в одном файле? И большие это сколько? больше 1 гигабайта?

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

вообще компилируемый язык программирования очень сильно отличается от интерпретируемого по скорости выполнения.

XML имеет много лишних элементов. это дополнительные операции по чтению/записи.

две базы (XML и MySQL) при равном количестве записей будут иметь сильно разные размеры. MySQL будет в разы меньше XML.

 

[medvoodoo]

:
>две базы (XML и MySQL) при равном количестве записей будут иметь сильно разные размеры. MySQL будет в разы меньше XML.
поспорю. зависит от данных
>XML не дает возможности сохранять индекс.
RTFM, с ключами у нее неплохо
>XML тормоз на больших данных. Это уже не отрицает никто. Народ уходит в сторону JSON
Вы о чем? Если в js то да, а вот читабильность конфигов никто не отменял.

а теперь ИМХО: Сравнивать СУБД и ХРАНИЛИЩЕ ДАННЫХ неправильно. Выгода файла-хранилища- когда идет потоковая запись, в этом случае мускул сливает неподетски.
Собственный аналаг MySQL с xml вы организовать не сможете(знания не те, сомневаюсь что кому- либо из здесь присутствующих это вобще по зубам) т.к. это не только хранение данных но еще и операции над ними, такие как многопоточный доступ /транзакции, кеширование, сложные выборки.

Так что советую не парится и работать с MySQL. XML лучше для вывода.

 

[Thoth666]

:
поспорю. зависит от данных

поспорить вы конечно можете... сравните текстовый файл с разметкой вида <value key="1" value="2 /> к примеру и файл где каждый байт используется по назначению.

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

>XML не дает возможности сохранять индекс.
RTFM, с ключами у нее неплохо

у самой разметки (файла XML) с ключами вообще никак.
а если говорить про конкретный обработчик XML, тогда возможны варианты.

Это все равно что спорить поддерживает ли база данных транзакции, без указания что это за база.

и фраза "RTFM" в данном случае не аргумент, а попытка уйти от аргументации

>XML тормоз на больших данных. Это уже не отрицает никто. Народ уходит в сторону JSON
Вы о чем? Если в js то да, а вот читабильность конфигов никто не отменял.

Так, секунда. изначально топик был про базу для чего?
Откуда появились конфиги? Опять-таки, конфиги конфигам рознь. Все зависит от того чем эти конфиги читаются (ось, язык).

а теперь ИМХО: Сравнивать СУБД и ХРАНИЛИЩЕ ДАННЫХ неправильно. Выгода файла-хранилища- когда идет потоковая запись, в этом случае мускул сливает неподетски.

Согласен на 100%
В случае если идет просто запись, без проверки значений, без проверки (к примеру) уникальности ключевых полей. Тупая запись. Да. Просто запись в файл будет всегда быстрее чем запись в файл с предварительной обработкой.

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

Вопрос в функциональности. Если мне к примеру нужны только выборки по ключам и обеспечение уникальности этих ключей, то лично я смогу создать СуБД, которая по скорости будет равна или быстрее чем MySQL. Но это будет работать только с моими данными и выполнять строго определенные действия.

Так что советую не парится и работать с MySQL. XML лучше для вывода.

воистину

 

[aabramov]

2 года работали с Tamino. Плевались. Зареклись.

 

[Shreksan]

Есть мнение, что для небольших БД лучше все-таки использовать XML. Например, если у меня будет база из 3 таблиц по 20 записей в каждой, и больше мне не нужно. Что скажете на счет такого случая?

 

[aabramov]

Есть мнение, что для небольших БД лучше все-таки использовать XML. Например, если у меня будет база из 3 таблиц по 20 записей в каждой, и больше мне не нужно. Что скажете на счет такого случая?

Заметьте, Вы сказали "база из 3 таблиц по 20 записей" - это уже реляционный подход. Вы в голове спроектировалим базу реляционно. Зачем в таком случае xml?

XML база может быть удобна/полезна когда отношения между объектами сложные и "криво" описываемые реляционной структурой - деревья, сети и т.п.

 

[medvoodoo]

Решил таки ответить:

поспорить вы конечно можете... сравните текстовый файл с разметкой вида <value key="1" value="2 /> к примеру и файл где каждый байт используется по назначению.

<xml><data>test</data><demo><t1>preved</t1></demo> а теперь создаем соответственно зависимости в мускуле.Если данные не линейные, то xml удобнее и меньше для их хранения.

у самой разметки (файла XML) с ключами вообще никак.
а если говорить про конкретный обработчик XML, тогда возможны варианты.

так же как и у бд MySQL, я имел в виду минимум xpatch и xslt

Это все равно что спорить поддерживает ли база данных транзакции, без указания что это за база.

и фраза "RTFM" в данном случае не аргумент, а попытка уйти от аргументации

ну ломало все это прописывать

Так, секунда. изначально топик был про базу для чего?
Откуда появились конфиги? Опять-таки, конфиги конфигам рознь. Все зависит от того чем эти конфиги читаются (ось, язык).

Оттуда же что и джейсон

Вопрос в функциональности. Если мне к примеру нужны только выборки по ключам и обеспечение уникальности этих ключей, то лично я смогу создать СуБД, которая по скорости будет равна или быстрее чем MySQL. Но это будет работать только с моими данными и выполнять строго определенные действия.
воистину