在练习中是否有任何错误，包括为每个帖子（已创建）创建物理目录以及每个用户（谁注册）在网站上？
对于类似的架构：
www.site.com/u/john
www.site.com/u/mike
www.site.com/post/za634df
www.site.com/post/df124zs
（PHP，基于Linux的FYI）。
我确实认为我需要一个物理文件夹，如果我想要一个帖子URL能够在Facebook上共享等等。这是真的吗？
另外，通过这样做，我会遇到问题吗？减速？服务器目录限制？等
答案 0 :(得分：1)
为什么要为每个用户创建多个目录，并在每个目录中添加相同的代码，只需使用单个脚本中的rewrite url处理所有目录。
多个脚本还会花费更多的存储空间，并且会在您的网站中更新或添加一些新功能时让您哭泣。
答案 1 :(得分：1)
我认为这不是一个非常好的主意。首先，它操纵文件系统的速度比在数据库中输入的速度慢，因此存在明显的性能损失，并且子目录的数量可能有限depending on the filesystem（这可能会导致长期的可移植性问题）。可能还有其他影响，但这些影响只会带来非常大的流量。
但是设计视角在这里更为重要：物理文件结构是一个完全不同于URI布局的层，它是一个抽象。通过将URI方案绑定到物理布局，您可以放弃此抽象的优点。像往常一样的设计原则，如果您的项目规模小，寿命短，或者您匆忙而且不在乎，这似乎不是什么大不了的事。但从长远来看，保持关注点的分离对每个人的理智都至关重要。
也就是说，如果实施得当，你的想法可能会有优点，但在我看来，使用数据库和URL重写引擎（比如Apache的mod_rewrite）会更好，以达到同样的效果。即使你最终为所有内容创建文件夹，也要确保程序是正确抽象的，并且没有任何代码依赖来处理同一目录中的内容，并且没有任何代码实际操作文件系统dirctly（依赖于一个统一的帮助器类来完成它）。
哦，不，Facebook无法看到您的URI方案背后的原因。