Новая тема   Ответить

 example
После многих часов поиска, мозг отказывается понимать выдаваемое гуглом немерянное количество текстов, преимущественно написанных в начале этого тысячелетия, на запрос что в сабже. Помогите не сойти с ума, расскажите, в 2х-3х словах, что юзать эффективнее для БД?
База планируется не большая, что-то около тысячи (или это большая?) записей.
Нагрузки: ~ раз в неделю обновление базы и трафа ~ 1-2k в сутки.

 Corex
Тысяча записей и 1-2К трафа в сутки - не та ситуация, когда стоит думать о выборе между XML и MySQL.

MySQL запросто держит в сотни раз больше. Пример из личного опыта - небольшое комьюнити, база 200К записей, трафа около 12-15К в сутки, средняя сессия на пользователя 20-30 минут и больше десятка кликов, обычный шаред хостинг. За 4 года работы этого проекта ни разу не было даже проблем с хостингом о превышении системного ресурса, а тормозов и отказов базы тем более. Конечно, при этом важна архитектура базы и правильная работа с ней из языка реализации программы.

XML (как подгруппа flat databases) может быть эффективнее, когда есть сравнительно небольшое число записей (несколько тысяч), огроменный трафик (в несколько сотен тысяч) и необходимо частое и простое считывание данных.
Но тут, опять же, важна архитектура и организация. Если засунуть 1К записей в 1 файл и при каждом запросе парсить его (а это выгрузка всего файла в память), то будет притормажить при каждом запросе. Flat database лучше делать по принципу 1 запись = 1 файл, а файлы раскиданы по 3-4-5 сотен в разные папки.
Ну и самая большая проблема базы на файлах - поиск. Если нужен поиск или сложные группированные выборки, то лучше юзать обычную базу.

 Sicilian
cогласен с Corex -

MySQL в данном случае полностью справится с задачей, да ещё и немалый "запас прочности" останется, поэтому нет смысла ломать голову, разбираясь в доках по XML )

 Pentarh
А к XML ты сам драйвер писать буш?

Делать больше нечего...

 example
Pentarh писал: Какой еще драйвер?

 True Alex
Ну если это база - с ней надо как-то общаться, для этого нужен драйвер или что-то типа. По умолчанию для работы с XML есть только парсер.

Вообще постановка вопроса неправильная. MySQL - это сервер баз данных, XML - язык разметки.

 example
True Alex писал: А что, готовых решений не существует? Обязательно самому писать надо?

True Alex писал: Ну да, и на ХML базы не делают?

 IDmark
Все зависит от цели и сферы использования!
В первую очередь нужно сразу разделить понимание:
Хранение данных и Обмен данными и Работа с данными.

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

К примеру, для большинства партнерских shop-ов куда проще и рациональнее использовать xml файл с базой товаров, чем дамп таблиц MySQL.

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

ИМХО для перечисленных тобой целей используй MySQL и не мудри с XML. А там дальше сам поймешь.

 idk2045
mysql однозначно, нафига плодить какие-то полурешения.
потом тока проблем огребешь.
mysql дешевле и проще в плане кодинга и намного эффективнее, короче одни плюсы)

 zuborg
Что касается выбора между mysql и xml, то в данном случае mysql конечно выглядит предпочтительней

Но есть и другие варианты, например плоский текстовый файл, или файловая база-хеш (например bdb или cdb). Несмотря на очевидное ограничение в функциональности и отсутствии поддержки реляционных запросов - нагрузка на систему будет ещё меньше чем при использовании mysql и появляется ощутимый бонус в надежности решения - mysql то может и лежать, но файловая система наверняка будет работать всегда.

ЗЫ: а кривые руки могут испортить что угодно.

 iRoot
Видимо zuborg: никогда не использовал "плоский текстовый файл" в системах, где больше одного пользователя одновременно работают, тогда бы такое не предлагал в принципе.
Так что используйте СУБД и не выдумывайте велосипед.

 zuborg
iRoot писал:

Для людей, не знающих flock, я и не предлагал.
mysql тоже использует файлы (не совсем "плоские", но тем не менее), но ничего, живет при больше чем один пользователе.
Все зависит от способа использования.

Кроме-то, плоский файл очень даже неплох при небольших размерах базы для предполагаемой нагрузки (обновление раз в неделю). Вон, до сих пор живы скрипты которые пихают ипы ботов как Deny from 1.2.3.4 в .htaccess (абсолютно плоский файл) - и живут вполне успешно пока размер файла небольшой (то есть до поры до времени).

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

 iRoot
Точно! А я дурак, все думаю нафига вообще выдумали управление конкурентным доступом с помощью многоверсионности, если есть такой простой выход как flock!
Уже побежал все переписывать на плоские файлы!

Еще немного покритикую хеш-файл: с ним есть проблема, что нет способа получить с его помощью выборку по промежутку, только по значению, а это очень серьезное ограничение.

 MoriArty
народ, ну чё вы ... ;)
ессно, для каждой задачи своё решение, и ИМХО, в данном случае, ТС следует однозначно выбрать мускуль, ибо он для этого и предназначался.
Однако, в защиту XML-я могу сказать следующее: если презентационная часть (ака Шаблонизация) построена на связке XML/XSLT, то композитное XML-кэширование конечных данных модели (собственно данных, полученных из того же мускуля, и обёрнутых в XML), здесь будет очень кстати. ИМХО, это единственная польза от XML в этом проекте, тех. параметры которого описал ТС.

зы: salvador, может быть ты имел ввиду XML DataBase, и просто слегка смешал эти технологии? Если да,- то к сожалению, мускуль нейтивно ни XML ни XPath до сих пор не умеет, и лучшее со всех сторон, в данном случае:
- Мускуль, как СУБД проекта
- XML, как конфиги и неменяемые данные, по которым не нужен поиск, а только выборка и возможно последующие преобразования

 MoriArty
Оффтопик: iRoot, а мускуль разве версионник?

 Sterx
Оффтопик: народ, объясните а преимущество шаблонизатора на xslt в чем?посмотрел hostcms так и не догнал

 MoriArty
Sterx:, первый, и пожалуй самый адекватный: возможность быстро и просто генерить конечное представление под разные клиенты (html/xhtml, wap, pdf и т.д.), второй, за который цепляются большенство идеологов - общепризнанный стандарт W3C, ну и третий, как следствие - переносимость презентационного слоя на другие платформы (например с mysql+php на java+oracle и т.д.). Остальное,- это вопрос религии, плавно перерастающий в холливар ;)

зы: ну и собственно сам холливар (кстати, очень позновательный) , ознакомившись с которым, можно решить для себя - нужно ли вам XML/XSLT или нет ;)
http://habrahabr.ru/blogs/about_cms/22018/

 iRoot
MoriArty писал:
Кеширование данных модели в XML это конечно жестко... мне сложно даже представить как можно так спроектировать БД, чтобы XML-кешированные данные модели (и все связанные с этим проблемы) давали прирост в производительности.

MoriArty писал:
http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html
Там конечно еще работать и работать в этом направлении, но что-то уже есть.

MoriArty писал:
Да, несколько лет уже... но мало кто об этом знает и еще меньше кто этим пользуется. В будущем поддержка будет только расширятся. Ведь его используют конторы, которые понимают, что метод "ЗАБЛОКИРУЙ ВСЕ, А ПОТОМ РАБОТАЙ" не подходит.

 iRoot
Sterx: у XSLT-трансформации при всех ее неоспоримых достоинствах, есть огромный и жирный минус, который не позволяет этой технологии завоевать мир это ее дикая тормознутость по сравнению с компилируемыми шаблонами и эта проблема, похоже, так и не будет решена. Так что ждем новых процессоров, которым все ни по чем и смело внедряем XSLT!

 Stek
А из XSLT можно сторонний php код, файлы инклудить ? Ведь стандартная ситуация "а вот у нас есть тут есть скриптик, как нам его на вот эту страничку вот в это место воткнуть".

 zuborg
Вот "нравятся" мне такие люди - научились молотком орудовать и давай все подряд им клепать - и шурупы вворачивать, и дрова рубить... Без обид!

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

mysql хорош для своих задач, но нельзя ж абсолютно игнорировать оверхед на сетевой коннект к мускулю, подготовка и пересылка запроса, парсинг запроса мускулем, подготовка плана выполнения, выбор строк в базе которые попадают под where, составление результата для нашего запроса, пересылку его обратно, получение клиентом и декодирование в внутренний php формат (а ещё кучу подробностей пропустил).
В условиях плоского файла это будет несколько системных вызовов (stat,open,read,close) и парсинг средствами пхп или его модуля (смотря какой формат). В случае XML расходы на такой парсинг очень значительны, увы.

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

Всем peace.

 MoriArty
ок, не хочу холливарить - не тот форум, и многим будет не интересно, поэтому просто высказываю своё ИМХО

мне сложно даже представить как можно так спроектировать БД, чтобы XML-кешированные данные модели (и все связанные с этим проблемы) давали прирост в производительности.
а кто говорит про полное соответствие DB и модели? я даже не упоминал Active Record и ему подобные. Кэшируются результирующие данные модели/бизнес-логики, которые могут и не быть просто выборкой из базы (и в большинстве случаев не будут её являться). Конкретный пример - сложный расчёт баланса некой организации, развёрутые статсы биллинга (где при расчёте берутся множество параметров, среди которых - вычисляемые на основе других), и т.д., когда последние производятся при множестве заданных параметров. Предлагаете каждый расчёт держать в базе или производить те же самые вычисления, или закешить ненадолгое время? РАЗУМЕЕТСЯ, это рулит когда презентационная часть (ака Шаблонизация) построена на связке XML/XSLT

Там конечно еще работать и работать в этом направлении, но что-то уже есть.
ну я года два назад и 6й мускуль чисто дома юзал, когда стебл до сих пор 5.x. Всё что стянуто с dev.mysql.com лично мне (и ессно большенству хостеров) юзать стрёмно.

Говорить "однозначно подходит" в условиях неполных данных несколько наивно
Возможно, я где-то и наивен, прочитав вот это ...что юзать эффективнее для БД?, и посоветовав мускуль ТС, но я руководствовался соображениями не академической заинтересованности ТС в изучении различных технологий, а исходил из вопроса рациональности: ТС не нужно практиковаться в построении реляционной базы, заморачиваться с организациями индексов, "целочной ссылостности" и всего прочего, ему просто нужно сделать небольшой проект с небольшими нагрузками не ради интереса, а исключительно исходя из соображений "отбить бабло", и чем быстрее, тем лучше.

зы: ИМХО мускуль - лучший выбор
зыы: холливар прекратил ;)

правка: сорь, сразу не заметил
А из XSLT можно сторонний php код, файлы инклудить ?
То, что имелось ввиду? - http://phpclub.ru/faq/PHP5/XML (Вызов PHP-функций)

 example
MoriArty писал: Так и есть

Спасибо всем за ответы (+8 каждому), я понял, что XML мне не подойдет. Склоняюсь в сторону MySQL, но есть еще мысль заюзать SQLite.

 Stek
Цитата:
а еще есть postgres, firebird, бесплатная версия sybase, оракл тоже как то там бесплатно на определенных условиях ... но нафига все это ? Используй мускуль и не создавай себе лишних вопросов, так как у каждой базы будут свои плюсы и минусы.
Но для вэба, в 99% проектах, мускуль является оптимальнейшим вариантом.

 example