хотя мог перепутать и я

и реально предлагаю сделать nested set но назвали nested tree

в гугле это одно и то же понятие

файлы только приватные. в БД хранишь пути к ним, и раздаёшь доступ юзерам.
по запросу, если у юзера есть права, просто делаешь Storage::download()
если будешь класть файлы через Storage::put(), они все будут лежать в одной папке, когда кол-во достигнет десятков тысяч, будет трудно в поддержке.
поэтому лучше каждому файлу назначить уникальный ИД, и строить папку вида AA/BB/CCDDDEE...
желательно хранить в базе также sha1_file() хэш каждого файла. если кто-то загружает файл, который уже есть, можно просто сделать ссылку, не создавая копии.

Спасибо, но от этого Спати не хочу ничего ставить))) У него все закручено очень. Хотя можно это и самому сделать за такое время, которое потратится на подключение его модулей.
Но, спасибо, гляну его наработки.

если БД — постгрес, сделай поле UUID, оно хранится в виде двух 64-битных чисел, и быстро обрабатывается в кач-ве PK.

в mysql же тоже можно, через binary

тот же UUID, кстати, по размеру точно равен md5-хэшу, т.е. в нём можно хэши хранить тоже

За хеш спасибо!!!
А так "тысячи файлов" не будет. Т.к. у кажого пользователя своя папка и обьем файлов.

хаха, все говорят "тысяч файлов не будет"... а потом со временем оно так засрётся, что взвоешь =)

а int медленно?

Не нее)) Каждому пользователю можно до 30мб загружать. И у каждого пользователя своя папка.
Вот и не будет тысячи файлов в одной папке :)

Спасибо, учту!

/stat@combot

Total messages: 447673

тысячи файлов по килобайту

наоборот, очень быстро, но int — это скорее serial, т.е. ИД у каждого файла будут идти по-порядку, что не есть айс: юзер будет у УРЛе подменять ИДшки, чтоб посмотреть, есть ли там чо

/link@yetanotherstatsbot

UUID для того и рекомендуется, чтоб ИД были непоследовательны.
причём, никто не мешает держать PK в SERIAL/BIGSERIAL, а рядом другое поле UUID, которое в ларке пропишешь как slug для модели

я у себя, кстати, предпочитаю именно этот вариант с двумя полями