Переплюнуть Google

до сих пор считал, что связано со скоростью, после ваших слов вкрались жуткие сомнения :D

Спасибо за литературу - нашел в груде книг книжку по Perl, с которой начинал его изучение... часа за 3 вспомню всё, надеюсь... Плюс литературу почитаю, - надо "добивать" этот проект, - хотябы бету (более-менее шуструю) выпустить для начала, а потом уже оптимизировать... Нельзя же пользователя заставлять ждать целую минуту на загрузку...

Еще раз спасибо за обсуждение всем участникам.

К стати, посмотрел редактор, который скачал, - ничего так редактор:

есть дебаггер (большой плюс), пошаговая отладка...

можно отслеживать std::id, std::out (в перле по-моему это просто STDIN, STDOUT)

единственный минус, - не подсвечивает для функций аргументы (обязательные и опциональные, т.е. вообще никакие), - просто очень привык пользоваться PHP Expert Editor - там очень удобно - вводим любую функцию (кроме юзерских функций), ставим скобочку и получаем список параметров, а также краткое описание того, что функция делает и что возвращает... Не хватает этого ((

может быть оно того стоит, но я пока что фришный поюзаю ))

Пардон, я там думал А а написал Б. Уже поправил. Доказать естественно я это могу, да вы и сами можете, неужто не умеете время засекать? Возьмите файл метров 10 (в котором ну например по 1000 байт запись) и таблицу из 1000 записей. Сравните время загрузки файла в массив и

select * from `table`

while ($k=mysql_fetch_assoc($r))

  $values[$k['id']]=$k;

ЗЫ. Учебников я не читал.

Засекал и не разю Именно это и указал. Пока файл небольшой.. по идее до 64М - файло быстрее. Естествеено если используется Perl CGI и перед работой "влоб" была сделана минимальная удобная разметка.

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

Ну а если говорить об использовании БД в CMS - так это классический пример нежелания людьми пользоваться головой или "жгучее" желание пользовать рекомендации PHP.

штука суперская. И комода - тоже. Обратите внимание на такую славную штуку MLDBM 'DB_File'. Более быстрых способов доступа к небольшим массивам данных, на мой вгляд, просто нет. Прямой дамп памяти с переменными.

Ну самоучки у нас почти все, но и там бывают очень интересные штуки. Так вот. Еще одно замечание. Погоняйте свой метод при 10-100-1000 запросов в секунду. Почствуете разницу.

Ну в общем то я именно это и утверждал. И без разницы перл это, пхп или brainfuck. Размер файла кстати не имеет значения. fseek() одинаково быстро работает что на мегабайтном, что на гигабайтном файле.

А вы мне представляетесь классическим примером программиста на перл =)

Главная причина использования БД в CMS - Это безопасность. Вторая причина - сделайте поиск по сайту с движком на файлах, сделайте интернет-магазин на файлах... тогда и расскажете про нежелание пользоваться головой :)

очень ошибаетесь. Очень! Хотябы из-за того что пхп работает по технологии ASP, правда у него чуть удобней реализованы библиотеки.

я же говорил, что не стоит пользоваться "решением в лоб"

если говорить о веб-скриптах - да, я считаю, что более удоного чем перл пока не появилось. Возможно - появится.

Вы сами в это верите? Вы считаете что база спрятанная за mySQL/MSSQL пленочкой - безопасно. Боже. Полный смех.

приезжайте, на самом деле. Покажу. И не только инет магазин. И еще много другого.

да, здесь этот сайт уже показывал, могу показать и еще раз. http://redday.ru

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

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

А база, к которой можно подключиться только с одного айпи, уж явно безопаснее, чем файлы, лежащие на хосте с правами как минимум owner+write

neolord, внимания Вам не занимать. Без обид.

БАза защищена лишь тем что кней нет доступа по HTTP. Зачем же файлы выкладывать так, чтобы их из HTTP можно было достать?

нет, я говорю не о хттп конечно. иньекции, загрузка shell-файлов и прочая.

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

А вот например делать "сравнение товаров" или выборку из каталога товаров по отдельным полям - на файлах это будет чересчур ресурсоемко, как бы вы не выкручивались. Тут дело в простой математике - многомерный поиск в одномерной структуре имеет сложность O (N^k) в общем случае, где k - размерность маскируемого вектора. В базах это ускоряется засчет индексов, пула и так далее. Если вы это реализуете самостоятельно - что ж, значит вы сделали собственную СУБД. База это ведь в конце концов тоже тупо файлы. Только зачем?

поверьте, - это очень просто. Просто стоит вопрос, что вы считаете файлами и что базами. Нагрузка на сервер от SQL сервера становится оправданной, если объем обрабатываемых файлов значительно больше свободного ОЗУ и нет необходимости вести полнотекстовый поиск.

Да тут я с вами и не спорю. Просто Вы пытаетесь сравнить 2 решения, которые в такм виде не сравниваются. Типичный пример, как Вы думаете, за счет чего серверный скрипт исполняется настольок быстро? Надеюсь Вы не думаете что он исполняется обработчиком как интерпритатором.

Там используется, промежуточный, некоторые его называют P-code.

Так почему-же Вы сравниваете подготовленную файловую БД и простой неподготовленный текстовый файл? Кто мешает его подготовить, возможно разбит на фрагменты, в момент импорта данных на сервер?

Я знаю что такое P-Code, Native Code и знаю как это работает. Это здесь не причем почти что.

Просто я не понимаю как может быть значительный выигрыш в скорости, если по сути вы своими подготовленными файлами и индексами сэмулируете работу СУБД. Неужели вы настолько хороший прогер, что единолично переплюнули все архиэпическую команду разработчиков MySQL и его 20 летнюю историю? Т.е. они там в крестики-нолики играют а вы изобрели способ как из той же файловой системы и мощности сервера извлекать на x% больше производительности без потери в функционале?