【问题标题】:Models + Database design模型+数据库设计
【发布时间】:2011-04-16 12:34:29
【问题描述】:

我想要完成的事情:

  • 图片应为单张图片或相册中的图片
  • 带有页码的相册和单张图片的可浏览列表
  • 浏览时不显示相册内的图片,仅显示相册封面

到目前为止,我的方法是:

  • 代表单个图像和单个专辑的模型
  • 一个数据库表内容,包含id、title、thumbnailFile和imageFile等。
  • 一个数据库表相册,包含相册 ID、相册标题等。
  • 一个数据库表album_content映射什么相册里面有什么内容
  • 一个数据库表浏览,其中包含专辑的 ID,以及不在专辑内的内容的 ID + 用于缩略图预览和排序的复制属性(文件名、标题、视图、日期等)
  • 分页器仅使用后一个表,而视图使用指向内容表的模型

我不认为上面的速度太糟糕了,但我觉得它不是特别优雅,我正在寻找一种更好的方法来做到这一点,并希望减少缓存/无效的元素数量.到目前为止,我一直在考虑以下几点:

  1. 数据库中只有一个数据副本(以某种方式组合内容、相册和浏览,并且仍然能够按日期、视图等快速计数和排序数据集)
  2. 远离任何可按列排序/排序的联接
  3. 将所有图像视为单个模型实例,也在相册内

我的主要问题是专辑的日期、观看次数等与其中的内容无关,我希望按不在专辑内的内容的日期+应该具有唯一标识符的专辑日期进行排序。相册也有与内容无关的列。

有什么好办法解决这个问题吗?

*编辑:为了速度,我想我只能使用单独的浏览表。有没有办法让 Zend dbTable 引用浏览 专辑和内容的视图列,以便专辑或内容中的 onUpdate 使用 Zend 中的 CASCADE 逻辑来更新两个表?

【问题讨论】:

  • 一张图片可以出现在多个相册中吗?一张图片可以是单张的,也可以是专辑中的?一张图片可以在同一张专辑中出现多次吗?相册可以没有图片吗?您要浏览同一列表中的单个图像和相册吗?

标签: php database database-design


【解决方案1】:

我会在后台编写代码:1 张单张图片 = 1 张专辑类型为单张。因此浏览单个图像与浏览相册是一样的。唯一的区别是当您显示“单图像”相册或“普通”相册时。 这是有道理的,因为专辑和单张图片都有一张图片来代表内容(图片或封面)。

表格可能是这样的:

t_album (id, type, title, cover_id, ...)
t_image (id, link, thumbnail_id, ...)
t_album_contents (id_album, id_image, comments)

请注意,表 [t_album_contents] 仅当图像可能在多个相册中或可能在同一个相册中多次出现时才需要。否则此表可能会消失并被表 [t_image] 中 [t_album] 上的外键替换。

【讨论】:

    【解决方案2】:

    首先坚持使用规范化数据库 (3NF) 总是一个好主意,然后根据您使用的 DBMS 进行运行时优化(仅在您确实必须时才违反 3NF)...

    再一次,我不能说得足够清楚:以任何可接受的代价避免违反 3NF

    如果您添加违反 3NF 的内容,请确保数据库的 3NF 部分在所有可能的情况下都保持完整……您的冗余“复制属性”可能导致数据不一致,因此请确保冗余中的数据您模型的免费 3NF 部分具有优先权……例如。当服务器负载允许时,定期从 3NF 部分重建冗余部分,或提供经过测试的更新模式,确保更新仅应用于 3NF 部分,并且 3NF 部分的每次更新都会触发相应冗余数据的重建......当您出于从数据库读取时的性能等原因需要冗余数据时,这样的方法会尽量减少数据损坏的风险

    将数据库的 3NF 部分与其他部分分开也是一个好主意(通过命名空间/前缀/等)

    根据预期的请求(浏览请求的数量与更新/插入请求的数量),是否对冗余数据使用建议的方法可能是有意义的。在速度方面不要低估正确的表索引。

    关于比较(排序)专辑与其他内容混合的问题:

    为什么内容实体不能代表专辑?专辑就像一个目录……它可以有子目录,从目录的角度来看,这些子目录是内容……如果以这种方式建模,您可以将内容与内容进行比较……额外的属性,具体取决于特定的内容类型位于另一个具有 1:0-1 关系的表中,而“常见”可比较属性位于内容表中

    另一方面,您可以使用 union vor this 理想情况下它只会慢一点,但可以使两种类型的实体统一进行比较和排序......根据预期的请求,缓存这些可能是有意义的每个可浏览对象的排序结果

    希望对你有帮助

    【讨论】:

    • 我尝试了联合方法,该方法速度要慢得多,因为数据库在对其进行排序之前为整个数据集创建了一个临时表(例如,对其他表中存在的数据进行排序)。我的浏览表或多或少是这个临时表的存储版本。我查看了 mysql 的触发器,但我不确定这是否是更新此浏览表的好方法,以将逻辑排除在我的模型之外
    • 所以您的 DBMS 是 MySQL ...如果您想保持缓存更新逻辑接近数据库,您应该考虑处理更新和插入情况的存储过程...阅读时,您的应用程序逻辑可以在需要时简单地使用缓存表(在数据不一致的情况下可以很容易地重建),但如果必须的话也可以访问规范化的数据......因为更新和插入仅限于存储过程,所以只有一点您必须密切关注缓存更新
    猜你喜欢
    • 1970-01-01
    • 2021-07-21
    • 1970-01-01
    • 2014-02-25
    • 2021-03-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多