3

对于相册，我看到大多数人使用 3 张桌子：

相册照片相册。

但是，如果我查看像 facebook 这样的网站，此架构将不起作用（如果我理解正确的话），因为我的个人资料相册和普通相册中可能有一张照片，但我可以为同一张照片提供不同的描述、不同的标签等。甚至照片身份证不同。所以我的猜测是，每当用户创建照片的副本时，它都会被视为全新的照片，因此我们只需要两个表：相册和照片（对相册有 FK）

其他选项是只有 1 列 (photo_id) 的照片表，并将所有照片详细信息放在 PhotoAlbum 表中，这样我就可以为每个相册提供每个独特的属性。

我在这个设计中有效吗？

4

3 回答 3

2

Photo<- Photo_Album-> Album。是关系，所以将各种有效负载（描述、标签等）放在Photo_Album表上（以及照片本身），这样当照片在数据库中时，相册中照片的每个实例也会被标记/描述。

然后，您可以聪明地了解如何将这些数据合并/显示给用户。

另外，不要忘记 Facebook 不是关系模型。出于扩展的原因，它是一个“NoSQL”风格的数据库，并且工作方式非常不同。您可以在 Google 上查找“NOSQL”以获取有关该思路的更多信息。

于 2011-01-06T22:35:42.607 回答
1

在关系数据库中，Photo/Photo_Album/Album 是存储数据的常规方式。原则是您只存储一次照片（或单个实体），但使用其他其他机制来提供您需要的最终用户功能。

您实际上不需要在照片的数据库中创建“副本”来应用不同的元数据。您可以在与包含此元数据的 Photo_Album 表相关的表中拥有元数据（不同的标签、描述等），而不是将其保存在 Photo 表中。这样，对于照片和相册的每种组合，您将拥有不同的元数据。

通过使用这三个（从技术上讲是四个）表相关的方法，您可以拥有关于照片或专辑或两者组合的元数据。

当然，这一切都取决于您的最终状态和潜在的未来需求，但这种设计模式的重点是将您的数据库视为一个独立的、经济的和优化的数据存储系统。然后，您使用 SQL/TSQL 和许多其他“中间”机制来为您的 GUI 提供接口。

于 2011-01-06T22:55:07.837 回答
0

在关系数据库中，Photo/Photo_Album/Album 是存储数据的常规方式。原则是您只存储一次照片（或单个实体），但使用其他其他机制来提供您需要的最终用户功能。

您实际上不需要在照片的数据库中创建“副本”来应用不同的元数据。您可以在与包含此元数据的 Photo_Album 表相关的表中拥有元数据（不同的标签、描述等），而不是将其保存在 Photo 表中。这样，对于照片和相册的每种组合，您将拥有不同的元数据。

通过使用这三个（从技术上讲是四个）表相关的方法，您可以拥有关于照片或专辑或两者组合的元数据。

当然，这一切都取决于您的最终状态和潜在的未来需求，但这种设计模式的重点是将您的数据库视为一个独立的、经济的和优化的数据存储系统。然后您使用 SQL/TSQL 和许多其他“中间”机制为您的 GUI 提供接口。您可以在http://www.albumkart.com上创建最好的相册设计和制作服务

于 2014-08-02T14:38:29.880 回答