вроде как твои религиозные убеждения заставляют хранить html в БД, если ничего не путаю.. но к чему бредить.. если известен точный путь к файлу и нужно прочитать этот файл целиком, то это будет в разы быстрее, чем получать тоже самое из БД.. зачем искать то этот файл?
QQQ Оставьте мои религиозные убеждения в покое, во имя Будды Может, будет быстрее. А может, и не будет. Я выше написал, почему "скорострельность" файловой системы начинает сильно страдать в случае большого количества файлов в одной папке - именно из-за невозможности использования индекс для поиска этих самых файлов. А искать файл все равно надо, ибо для открытия файла нужен, грубо говоря, номер кластера, а вовсе не имя. В некоторых ситуациях БД может оказаться и быстрее, особенно "карманные" БД, типа того же SQLite.
Да нет же, путь к файлу и сам файл интерпретируется ОС как всего лишь участок на винте под определённым адресом.А адрес не ищется он выбирается опять же из MFT.Но если бы перед каждой загрузкой и выгрузкой из оперативной памяти в виртуальную или из дискового пространства то и сейчашних мощностей "машин" не хватило бы.Представляете каждая операция выборки начинается со сканирования всего диского пространства каталога.Извините если я не правильно понял.
Мог бы злоупотребить правами root'а и поставить Options +Indexes для директории в одном уютном форуме, где сложены файлы картинок, прикрепленные к сообщениям. Вначале никто не ждал такой активности, но сейчас их там 17544 штуки. Возможно, стало больше, пока я это пишу. Войдя по ссылке в эту директорию, можно будет наблюдать процесс сканирования - и он будет действительно долгим. Войдя на страницу форума, где (по относительному пути и имени файла) вытаскивается несколько рисунков из этой же директории, никто не обнаруживает никаких тормозов. Потому что сканирования в этом случае нет. Есть обращение к файлу - дескриптору этой директории (физически директория - тоже файл). Грубо говоря, это и есть индекс. Пример форума совсем не уникален. Но что это мы все о грустном? Мини-движки не предназначаются для хранения энциклопедий, я не думаю, что в эту игрушку кто-то запихнет 10000 страниц. А если кто запихнет - выдержит, не развалится. Я для пробы набросал в один экземпляр около 500 - хотелось бы мне, чтоб движок с СУБД на том же хостинге ворочал их с той же скоростью... PS И это... сайт намеренно посажен на дешевый "односерверный" хостинг, нагруженный по самое некуда дальше. Не нужно его так агрессивно тестировать. Собственно, меня сюда и привело чье-то баловство, обнаруженное в логах в то же время, когда шла эта дискуссия. PPS Интересно, пожелавший остаться безвестным тестер удовлетворен результатом?
AHP-net Операции сканирования каталога выполняются и там и там, и при отображении списка файлов клиенту, и при выдергивании одного конкретного файла. Но в первом случае еще имеет место быть формирование HTML-страницы апачевским модом mod_autoindex, а также отправка этой страницы клиенту. Именно это и вызывает заметные на глаз тормоза. А задержку, вызванную необходимостью поиска файла в файловой системе, на глаз вы не заметите, как не заметите на глаз и время выполнения простого SQL запроса. Так что имеют место быть два похожих, но в то же время разных подхода к поиску данных. Очень низкоуровневое, но все же последовательное сканирование VS более высокоуровневое, но индексированное. Какой из подходов окажется в выигрыше - зависит от конкретной ситуации.