include в php большого файла

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

Остаются вопросы к надежности и удобству. 

Что это Вас потянуло на концепцию пан-сам-склепал, а не на энтерпрайсные решения?

Ну почитайте весь тредможет и не нужен будет мой ответ? Вкратце - стало интересно проверить, наклепал - убедился что со временем поиска больших проблем не будет. Понятно, что это только как студенческая лаба, такое решение никогда в жизни в прод не пойдет. Чисто сравнить скорость. 

Вы накидали в одну корзину совершенно разные ситуации без особого понимания этих ситуаций. Какое отношение роллбэк имеет к статично размещенному в директории файлу? Почему вдруг при бэкапе может быть ошибка и ее не может быть в базе данных? Не говоря уже о том, что база данных - это те же файлы на диске. Более того, если какой-то файл изменился в процессе создания бэкапа - об этом будет уведомление. Если он по какой-то причине не сохранился - так же.

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

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

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

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

А вообще, про реальную практику на проде я уже написал, поскольку сам уже несколько лет сижу на самописах на файлах, не используя БД в принципе. Понятно, что в БД  есть неоспоримые плюсы на соответствующих задачах, но на тех, которые описаны и поднимаются в этой теме - можно легко, безопасно и эффективно обходиться только файлами.

Ps: я уж не говорю о том, что часть задач по работе с данными в файлах можно выполнять более эффективными grep, sed, awk и т.д. и возвращать результат в оболочку сайта.

В построчном разделении мне нравится многое, но еще и это:

Если мы создаем файл с ID вида

ID1111
ID2222
......
IDNNNN

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

ID1111 _MY_SEPARATOR_ DATA222
ID2222 _MY_SEPARATOR_ DATA222
......
IDNNNN _MY_SEPARATOR_ DATA222

После чего ищем нужную строку с помощью аналога 

str.startsWith('ID1111 _MY_SEPARATOR_')

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

P.S. Эксперимент  Sly32  с написанием скрипта, опубликованного выше, получился интересным сам по себе. Замечал, что действительно хорошие программисты обычно сочетают качества экспертности и стремления к постоянным экспериментам. 

До тех пор, пока не выходишь на большие объемы, когда у тебя или с пол миллиона файлов для хранения данных или, когда у тебя во входящем разборе прилетает .xml на 300-500Мб одним файлом и нужно максимально эффективно использовать ресурсы сервера, чтобы не пришлось ради разбора этих разовых данных покупать тариф за оверпрайс денюжек ) А так, да, пока там условно 100 записей - разницы он не почувствует. Ну или, если есть возможности платить за более ресурсный сервер, не экономя свои средства.

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

P.S. Не увидел ответа пока переписывал последнее предложение. Затёр его случайно.

Ну ка бы и их тоже. Серваки у меня в среднем по 10 сайтов, ну типа чтобы всё не было "в одной корзине".

Ну как показала практика, разницы практически нет. +-10% роли не играют при примерно одинаковых итоговых объёмах.