对于相册，我看到大多数人都使用3张桌子：
相册 相片 PhtoAlbums。
但是，如果我查看像facebook这样的网站，这个架构将无法工作（如果我理解正确的话），因为我的个人资料专辑和一般专辑中可能有一张照片，但我可以给出相同的图片不同的描述，不同的标签等甚至照片ID也不同。所以我的猜测是，每当用户创建一张照片副本时，它就会被视为一张全新的照片，因此我们只需要两张桌子： 专辑和照片（有FK到专辑）
其他选项是只有1列（photo_id）的照片表，并将所有照片详细信息放在PhotoAlbum表中，这样我就可以为每个相册分配每个独特的属性。
我在这个设计中有效吗？
答案 0 :(得分：2)
Photo＆lt; - Photo_Album - ＆gt; Album。是关系，所以将各种有效负载（描述，标签等）放在Photo_Album表（以及照片本身）上，这样当照片在数据库中时，相册中每张照片的实例也是标记/描述。
然后，您可以聪明地将这些数据合并/显示给用户。
另外，不要忘记Facebook不是关系模型。它是一个“NoSQL”风格的数据库，用于缩放原因，并且工作方式非常不同。您可以在Google上查找“NOSQL”，以获取有关该思路的更多信息。
答案 1 :(得分：1)
在关系数据库中，Photo / Photo_Album / Album是存储数据的常规方式。原则是您只存储一次照片（或单个实体），但使用其他其他机制来提供您需要的最终用户功能。
您实际上不需要在照片数据库中创建“副本”以使其具有不同的元数据。您可以在与包含此元数据的Photo_Album表相关的表中具有元数据（不同的标签，描述等），而不是将其保留在Photo表中。这样，您可以为照片和相册的每个组合使用不同的元数据。
通过使用这三个（技术上很好的四个）表格相关的方法，你可以得到关于只是一张照片或只是一张专辑或两者的组合的元数据。
这一切都归结为你的最终状态＆amp;当然，潜在的未来要求，但这种设计模式的关键是将您的数据库视为一个单独的，经济的和优化的数据存储系统。然后使用SQL / TSQL和许多其他“中间”机制为GUI提供接口。
答案 2 :(得分：0)
在关系数据库中，Photo / Photo_Album / Album是存储数据的常规方式。原则是您只存储一张照片（或单个实体），但使用其他其他机制来提供您所需的最终用户功能。
您实际上不需要在照片数据库中创建“副本”以使其具有不同的元数据。您可以在与包含此元数据的Photo_Album表相关的表中具有元数据（不同的标签，描述等），而不是将其保留在Photo表中。通过这种方式，您可以为照片和相册的每个组合使用不同的元数据。
通过使用这三种（技术上很好的）表格相关的方法，您可以获得关于照片或仅仅是相册或两者的组合的元数据。
这一切都归结为你的最终状态＆amp;当然，潜在的未来要求，但这种设计模式的关键是将您的数据库视为一个单独的，经济的和优化的数据存储系统。然后使用SQL / TSQL和许多其他“中间”机制为GUI提供界面。您可以在http://www.albumkart.com创建最佳相册设计和服务