我正在拍卖上市项目。该项目的一部分允许用户上传他们将在特定日期出售的物品（有时是数百种物品）的照片。因此，我有多个问题都会导致如何有效地执行此操作，并且有效地允许在日期过后轻松删除。
1. 文件夹管理：我的想法是在每个日期中为每个日期的每个用户/列表提供其自己的文件夹，并且列表本身将拥有自己的文件夹，其中包含唯一标识符以防万一他们有相同日期的多个列表。所以文件夹架构将是：日期/用户/ uniquefoldername / images.jpg 想法？有没有更好的方法，请记住，我希望能够在日期过后轻松删除文件夹及其内容？
2。后果：我可能会在任何指定日期拥有多达1500个商家信息，如果每个用户添加100张照片（最差情况），任何指定日期为150,000或4,500,000 in一个月（用户可以提前一个月发布列表）。鉴于上面的架构会产生什么后果呢？除了大量的废话之外，我需要更多的存储空间！（我们将根据需要处理存储问题）。
3. 存储和检索：我的想法是只存储图像文件夹的路径，然后编写一个脚本来检索所有这些脚本，以便在设置的灯箱中显示（想想Facebook）。思考？有没有办法更有效地做到这一点？
4. 删除：我的想法是每天cronjob删除自列表日期起至少24小时后的所有文件夹，然后更新数据库以反映文件夹的删除避免ppl尝试查看已删除的图像。这可以有效地完成吗？我是否应该一次性删除所有内容或将其分解并按小时运行以避免服务器过载？
5。有更好的方法吗？在某些时候，我们将添加一个图像服务器或探索其他存储途径，但在此之前，我需要尽可能高效地执行此操作，以使服务器负载从后端继续运行
6。鉴于数据处理规模和删除过程可以在不牺牲服务器性能的情况下做到这一点吗？
一些背景信息：我们每天查看大约400,000次网页浏览量，因此每月有1200万次网页浏览量。我们期望超过1万名会员能够发布列表和超过10万注册用户（仅需要注册查看网站的某些方面）和每年1200万到1500万的独立访问者。当向公众呈现时，每个列表将与数据库中的4个表进行交互，因为它现在在纸上，显然这可能随着范围变得更清楚而改变。每天都会运行几个cron作业，其中2个作为服务器密集型，新闻通讯和照片删除。该通讯与数据库广泛交互，因为它将包含邮政编码特定数据，该数据在每个用户的基础上利用数据库中的表。因此，考虑到所有这些，您可以看到为什么我担心第一次使图像存储架构正确。