О да, офигеть структура сложная: id, файл в системе, реальное имя

По имени файлав системе(типа 12ab211d2bac12d) смотрится его путь(12/12ab/12ab211d2bac12d) и реальное имя.

2 nerezus
Ждал твоих комментов. Если не сложно поясни почему база быстрее файлов? Ведь она тоже на файлах. Это не спор, это вопрос, действительно интересно.
И если говорить именно о скорости, все же как будет быстрее, из оперативки брать данные или все же из базы? Ну если не трудно дай все же ответ чуть шире чем обычно

Ну тебе придется делать свое подобие базы в противном случае
Не будешь же ты хранить файлы под их реальными именами, а потом лазить по всем папкам в их поиске? %)

Хм... может я дурак... или неопытен, но вот нифига не понял.
Ладно, опыт придет. Спасибо и на том, будет над чем подумать, мало ли вдруг понадобится решать подобную задачу для чего нибудь своего.

3 поля в бд.
Индексное уникальное слово или автоинкрементное целое - это номер файла
Временное имя файла(сгенерировано скриптом)
Реальное имя файла(при отдаче подставляется).

Red_Red1 Наверное ты знаешь что БД развивается уже не один десяток лет, и даже в общих идеях и алгоритмах все более ли менее отточено. Взять хотя бы b-tree (сбалансированное дерево)... и представь поиск по нему, и поиск по харду... По сбалансированному дереву, при достаточно большом количестве записей ты получишь результат за 3-4 операции. Ну это я для примера, но общий смысл думаю понятен - почему база быстрее файлов.

2 VDShark. Конечно я понимаю почему база быстрее файлов и то как она ищет по индексированым полям. Идея моя в другом.
Вот скажи что будет быстрее сделать запрос в базу и обработать результат ИЛИ выполнить вот эту строку
Я не делаю ПОИСК по харду, я загружаю ОДИН конкретный файл. ИЛИ же как я предложил вообще забираю массив из оперативки используя кеш. Т.е. у нас уже есть нужный массив.

А что выведет эта строка?

Имя файла/папки.
Массив $arr хранит все дерево каталогов.
_______________________________________
Исправил код в предыдущем посту, допустил ошибку.