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

А заказчик и не должен уметь все это делать - это работа разработчика, настроить все так, чтобы клиент даже не думал, что там внутри. С таким подходом он не сможет и забэкапить файлы. О каких больших обьемах ты говоришь - я не понимаю. По факту ТС работает со списками ID. Работая с БД это несколько запросов, очень простых. Примитивные транзакции. С файлами нужно продумать хорошенько иерархию. Типа 100000.txt хранит айдишники до 100000, 200000.txt - до 200000 и тд. То есть я так понимаю, скрипт должен работать с произвольными именами, сначала определять в каком файле искать, открывать его, проверять на соответствие... 

Насчет надежности такого метода у меня тоже есть сомнения. Если файл открыт для чтения, а в это время в него будет писаться новый айдишник, что произойдет? У меня нет опыта в таком, а в базе я знаю как это будет работать. Достаточно  использовать ACID совместимые БД. 

а что по скорости тут?

Просто уточнил, нет придирок, может я не так прочитал)

Ну, в отличие от большинства местных графоманов, у тебя есть знания, вот мне и интересно стало уточнить. Все мы тут развлекаемся, но и учимся) По крайней мере некоторые. 

Да, извини, если резковато пишу. Пятница, после НГ работать лень, сижу вот на форуме 😀

По формированию файлов-партиций. Пишем какую-нибудь функцию-метод, например такой псевдо-PHP, насколько я его помню.

function getPartitionCodeByYouTubeId($ytId){
    $idFiltered = preg_replace('[^a-z\d]', '', strtolower($ytId));
    if(strlen($idFiltered) >= 2){
        return substr($idFiltered, 0, 2)
    }
    throw new IdErrorException(11111);
}

function getFileNameByYouTubeId($ytId, $fullPath = false){
    $partitionCode = $this->getPartitionCodeByYouTubeId($ytId);
    $fileName = $partitionCode . '.txt';
    if($fullPath){
        return '/my/directory/'.$fileName;
    }
    return $fileName;
}

Сюда пишем разные условия, пишем тест для этого кода и прогоняем его на большом объеме ID, проверить не выбрасывается ли Exception.

Главное, чтобы для каждого ID выдавались две буквы/цифры.

Этот метод вызываем и перед записью в нужный файл и при чтении из файла. Так мы узнаём куда писать и откуда читать.

Если с одной стороны файла его построчно читает интерпретатор, а с другой Unix-like OS пишет с помощью 

'some str' >> /my/file.txt

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

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

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

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

Для меня преимущества БД очевидны для эього кейса

К счастью, у меня таких нет)))

Хочешь сказать что копирование нескольких тысяч файлов будет быстрее?

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

СУБД тоже отлично подходят для большинства случаев.

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

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

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

классический unordered map

Скорость будет зависеть от глубины ведра (односвязного списка), которая зависит от качества hash-функции определяющей ведро.

В данном случае стоит идти дальше и строить дерево, добиваясь, чтобы в одном файле было не более 1-й строки. Условно брать md5 от имени файла, разбивать по 2 символа и каждый следующий уровень размещать в подкаталоге.

а-ля: MD5 (FileName) = 1e621df39e053ff6bc7db7bb1c616cc1

1e
  62
    1d
      ...
        c1

Мне кажется, ты счас описал NoSQL))) Ну примерно. Но правильно я понял - хэши имен файлов нужно где-то хранить? И тогда постоянно заботиться о целостности?