Ну, отчасти это зависит от того, что вы хотите с ними делать, и от того, что вы считаете большим числом.
Как и при индексировании столбцов в базе данных, эта схема может принести пользу некоторым операциям.и наносить ущерб другим.
Например, в простой схеме, в которой не была доступна дата, возможность найти изображение по части его имени может оказатьсянемного сложнее, так как вы не представляете, где это будет.Я использовал эту схему для таких вещей, как файлы журналов, но она работает хорошо, так как я уже знал , где она будет находиться:
/logs/2011/01/2011_01_14.log
, и мне не пришлось искать ее.
Теперь вы решили эту конкретную проблему, поскольку ваша запись в базе данных также содержит дату, поэтому я не вижу никаких непосредственных проблем с вашей схемой.Это не значит, что не любой: -)
Мой совет - сначала сделать простейшую вещь (формат плоского каталога) и беспокоиться об этом только тогда, когда это станет проблемой.Поскольку у вас есть даты, было бы просто переместить все изображения, основанные на этом, в отдельные каталоги.
Конечно, если вы уже реализовали отдельные каталоги, придерживайтесь этого.Опять же, мы надеемся, что в будущем это будет относительно легко настроить, если метод некорректен.
Одна вещь, которую может захотеть рассмотреть, - это сохранение местоположения (абсолютноеили относительно известной точки) в базе данных, а не только даты.Тогда вы будете использовать это (а не операцию над датой), чтобы найти файл.
Это позволит вам полностью изменить метод, используемый для размещения файлов, без необходимости изменения какого-либо кода, который их обнаружил.