我正在开发一个网站，上传到该网站的单个图像可以被多个业务模块使用，例如Food Item、Dish、Gallery或其他。
我有一个主图像表，用于存储对文件系统上实际图像的引用。
现在，该表上的每条记录都可以通过 item、dish 或 gallery 表进行引用。
我的问题是，所有这些引用应该存储在一个表上还是应该维护一个单独的表，如 ItemImage、DishImage？
单张桌子的问题是我担心这张桌子会被高点击量轰炸，最终会增加响应时间。多个表的问题是随着业务前端模块数量的增加，我必须不断添加更多表。
如果我说性能是我网站的重中之重，那么最好的方法是什么？
SQL Server 2012、.Net 4.5、MVC 4。
谢谢
我建议使用单个表。正如@Brandon 所提到的，如果索引正确，应该没有性能问题。
我还建议您仅存储来自公共根文件夹的相对路径（如 @SpectralGhost 所建议的那样）。然后，公共根文件夹可以作为配置设置，允许运营团队更改文件的存储位置，而无需对数据库进行大规模更新。
如果单个文件夹中有数千个文件，文件系统性能可能会成为问题。我建议为更多的树结构制作几个级别的子文件夹。例如，如果文件名ABCDE.jpg使用类似的路径，A/B/ABCDE.jpg则会将文件拆分为数千个子文件夹。
我还建议您使用 GUID 或类似名称作为上传文件的基本文件名，以避免任何命名冲突（并使用 GUID 的无破折号版本来保存 4 个字符）。如果您需要原始文件名，请将其放在图像表的另一列中。存储其他图像元数据，例如宽度、高度和内容类型（例如“image/jpeg”）也是一个好主意。
使用关键字标记系统对每个图像进行分类可能是对图像进行逻辑分组的最佳方法。然后理论上可以将每个图像分配给任意数量的类别（包括零）。这将需要一个标签列表表和一个包含(tag_id, image_id)对的单独映射表。
这就是索引存在的目的。将它们全部放在一个表中，只要它的索引性能对于这种情况就不会成为问题。
想想你是否有一本书，里面有 1,000,000 页。即使对于作为人类的你来说，找到任何给定的页码也不会花费那么长时间......只要页面是有序的。而且，您在 100,000,000 页的书中找到一页的时间差异确实不会显着延长。
现在，如果您对数据进行复杂的报告，它可能会有所不同，但这只是一个查找表。