file vs MySQL

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

А измеряется просто. Создаёшь таблицу в БД. Колличество полей на твоё усмотрение. В цикле делаешь порядка 3 - 4 тысяч записей, сначало в БД, затем в файл. Затем читаешь. Потом ведёшь поиск. Понимаешь что быстрее. Это касается плоских таблиц. Можешь поизвращатся с обеденением таблиц и имитация того же на файлах. Посидишь денёк и всё станет ясно.

можно описать функцию, которая покажет время генерации страницы, и попробуйте =) тем более при работе с БД гораздо удобнее получить нужную переменную, чем искать её самому в файле

ребята, мне не очень хочется читать книги по MySQL, чтобы выяснять, что эффективнее. можно сказать по-другому: если вы подскажите, насколько быстрее i/o строки а файл, чем в MySQL, я решу, следует ли учить MySQL :) . если знаете ответ -- очень прошу.

Если вопрос ставится "Стоит ли учить БД", то ответ тут однозначен - нужно.

тут даже не во времени доступа дело. ни одна более-менее сложная программа (или скрипт на сайте) не обходится без БД

Тут дело в исспользовании, а не только в скорости чтения/записи. Тупо записать в файл, безо всякой подготовки, скажем в начало файла конечно быстрее. Но врятли тебя устроит такая функционалность. Когда хранимые данные обретают более менее сложную(не абсолютно элементарную) структуру и объем(количество), то тут уже во главе угла стоит вопрос поиска и чтении/записи из/в нужного места. Тогда и начинают проявляться преимущества и недостатки разных подходов. Организовать грамотный поиск по своим файлам нужных данных да еще за приемлимое время задача не простая =) А данные в БД храняться в таких же файлах. Только вот в БД до тебя уже реализованна оптимизация поиска и доступа к данным (а чтение/запись из файлов и кэширование он делает уже сама). Ну и в добавок предоставляет такой мощный инструмент доступа к данным, как SQL. Поэтому хранить сложные данные в больших количествах естесственно всегда выгодней в БД и по скорости разработки и по скоросте обращения к ним и по надежности операций и т.п. - для того СУБД и создавались. =)

[QUOTE=koric]тут даже не во времени доступа дело. ни одна более-менее сложная программа (или скрипт на сайте) не обходится без БД[/QUOTE]
А вот по поводу ни одной более менее сложной программы - неправда. Эта сложная программа может просто не иметь необходимости в БД в принципе по своему назначению. =)) Не смотря на свою сложность =)

Если тебе нужно сохранить 1-10 строк - файл будет быстрее
Если больше - то БД. Поиск по большим массивам данных в БД намного быстрее чем в файле.

ребята, я понимаю, что структурированность -- это хорошо, что искать в обычном файле информацию неэффективно, что отлаженная DB намного лучше и т. п. просто ну очень хочется узнать, на сколько быстрее записать n строк в файл, а затем прочитать эти n строк из него, чем делать то же, но в MySQL. возможность быстрого поиска и структурирование информации не важны.
не хочу показаться совсем наглым, но очень прошу кого-нить, кому не лень, выяснить, сколько по времени (а лучше по тактам процессора) займёт запись, скажем, 100 строк (по 50 char) в MySQL и в файл. я просто совсем не знаком с этим делом :(.
заранее благодарен.

[QUOTE=smax13]ребята, я понимаю, что структурированность -- это хорошо, что искать в обычном файле информацию неэффективно, что отлаженная DB намного лучше и т. п. просто ну очень хочется узнать, на сколько быстрее записать n строк в файл, а затем прочитать эти n строк из него, чем делать то же, но в MySQL. возможность быстрого поиска и структурирование информации не важны.
не хочу показаться совсем наглым, но очень прошу кого-нить, кому не лень, выяснить, сколько по времени (а лучше по тактам процессора) займёт запись, скажем, 100 строк (по 50 char) в MySQL и в файл. я просто совсем не знаком с этим делом :(.
заранее благодарен.[/QUOTE]
Чем больше будет информации - тем больше разрыв будет нарастать. Если тебе нужны конкретные цифры - то тебе их никто не даст поскольку зависит от большого числа факторов: ОС, язык, тип БД, версия БД, структура данных и т.д. и т.п
Проводи сам эксперимент...
ЗЫ А можешь еще бросить монетку ;-)

[QUOTE=smax13]ребята, я понимаю, что структурированность -- это хорошо, что искать в обычном файле информацию неэффективно, что отлаженная DB намного лучше и т. п. просто ну очень хочется узнать, на сколько быстрее записать n строк в файл, а затем прочитать эти n строк из него, чем делать то же, но в MySQL. возможность быстрого поиска и структурирование информации не важны.
[/QUOTE]
Если просто тупо записать n строк за один заход а потом счиать все эти строки в одни буффер - то быстрее конечно =)
А конкретные цифры - они сильно зависят от файловой системы, функций ОС и СУБД, и реализации чтения записи в конкретном языка программирования =)
Собственно если задача стоит только в записи N байт в файл (считай n строк по m байт) без всякого разбора, и последующего чтения таким же макаром - то тут конечно БД нафиг не нужна, и будет только мешаться )

Раз уж товарищу это так принципиально, скажу следующее.

На первой сотне-двух файлов (скажем БД неких текстов) поиск и другие операции будут значительно тормозить диск, процессор и память. Ни один хостер этого так не оставит ;) Потом ты придёшь к тому, чтобы придумать некие алгоритмы оптимизации и т.д. В итоге в зависимости от опыта ты уткнёшься в необходимость создания собственного движка БД. А у нас в наличии уже есть множество пакетов, которые разрабатываются лучшими программистами много лет. Так что следует задуматься, зачем люди создавали СУБД???

В общем БД быстрее однозначно. Хотя бы из-за того, что основная операция СУБД - выборка - очень хорошо отточена за 30 лет существования БД.

Надеюсь я понятно изъяснился.

А если ты гонишься за милисекундами и тактами, то ты либо законченный маньяк (без обид ;) ) либо просто не разбираешься в сути вопроса (о чём кстати ты ясно дал понять своими постами).

Расставь цели, задачи, изучи средства и ты сам придёшь к решению своего вопроса.

З.Ы. - Что лучше: танк или пистолет? - вот о чём я подумал ))) К слову я храню в MySQL тексты статей, уже за 20000 перевалило и ничего. В другой БД я храню картинки (намучился с файлами). А разаботчики MySQL сообщают, что изх клиенты работают с более чем терабайтными файлами БД. Стоит задуматься.

>>А разаботчики MySQL сообщают, что изх клиенты работают с более чем терабайтными файлами БД. Стоит задуматься.
Они себе льстят) Ещё не встречал не одно разумное существо, которое такой объём в мускуле держало.

[QUOTE=shaelf]Они себе льстят) Ещё не встречал не одно разумное существо, которое такой объём в мускуле держало.[/QUOTE]
Полностью согласен. Для таких массивов данных есть настоящие БД.

[quote=foxweb]Что лучше: танк или пистолет? - вот о чём я подумал ))) К слову я храню в MySQL тексты статей, уже за 20000 перевалило и ничего. В другой БД я храню картинки (намучился с файлами).
[/quote] а зачем вы храните в БД картинки? хотите по ним полнотекстовый поиск делать? =)))
[quote=foxweb]
А разаботчики MySQL сообщают, что изх клиенты работают с более чем терабайтными файлами БД. Стоит задуматься.[/quote] во первых все "клиенты" имеют отюнингованный разработчиками Мускуль, который "немножко" отличается, от того, что используется обычно. об этом ребята из мускуля обычно скромно молчат. во-вторых, чисто объем данных - далеко не показатель.

конкретно по вопросу. автор! весьма кошерно было бы задачу озвучить. потому что все зависит тут именно от задачи. aks совершенно верно заметил - если нужно данные тупо писать в файл, а потом читать, то Б/Д вам абсолютно не нужна. сколько бы записей не было в вашем файле.
весьма бесят порталы, на которых все подряд суют в СУБД. и там, где достаточно было бы записать несколько строк в файл, делается несколько INSERT'ов, что МЕДЛЕННЕЕ. бесят форумы, где при одной только вставке поста выполняется по 30 SQL запросов... а все потому что некоторые не умеют инструменты выбирать. и забивают гвозди отверткой.

Однотипное хранение инфу позволяет сократить время разработки проектов и уменьшить колличество ошибок. Именно из-за этого они и хранят всё в БД.

[QUOTE=shaelf]Однотипное хранение инфу позволяет сократить время разработки проектов и уменьшить колличество ошибок. Именно из-за этого они и хранят всё в БД.[/QUOTE]
Однотипное однотипному рознь. Картинки, архивы, всякие pdf и doc нужно хранить, всё-таки, вне БД. Авторы этого движка (vBulletin, на котором этот уворум работает) дефолтом предлагают хранить вложения в БД, но при этом есть возможность всегда перекинуть все эти вложения в вид файлов (и, видимо, наоборот). Я посчитал, что отдельно их хранить - лучше.

[quote=shaelf]Однотипное хранение инфу позволяет сократить время разработки проектов и уменьшить колличество ошибок. Именно из-за этого они и хранят всё в БД.[/quote]
нифига оно не снижает количество ошибок, как показывает практика. а вот нагрузку на базу увеличивает на порядки.

[QUOTE=squirL]а зачем вы храните в БД картинки? хотите по ним полнотекстовый поиск делать? =)))[/QUOTE]

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

[quote=foxweb]Понимаю ваш сарказм, однако есть класс задач, которые можно обозвать как "интеграция сетевых приложений".
И по другому такую тривиальную вещь, как хранение картинок и передача данных не решить, либо решать отдельно и другими методами, чего делать очень не хочется.[/quote]
не понял. т. е. - если база хранит информацию о местоположении картинки, то выдать картинку гораздо сложнее, чем если хранить ее непосредственно в базе? и сложно это настолько, что можно игнорировать накладные расходы на хранение и выдачу картинки непосредственно из базы? :eek: