Tridion 和 PDF（大容量）内容管理

Question

我们有 5,000 个 PDF，总计不超过 200GB。它们可能需要在全年以大约 1,000 个为单位进行更新。

如我所见，有两条主要路线...

1) 通过 Tridion 发布 PDF 和相关元数据 2) 直接导入交付环境，在 Tridion 中管理 PDF 元数据

将这些 PDF 放入 CMS 的一个令人信服的（商业）原因是让它们投入生产的途径 - CMS=容易 - 非 CMS=根本不容易，而且它直接为企业提供了控制权。

我们当然更愿意管理与二进制项目直接关联的元数据，并利用组件链接（跟踪使用位置等）而不是将组件（用于元数据）与“链接”映射到非 CMS 控制二进制项目 - 所以在我看来 通过 CMS 会更有意义。

现在 - 存在膨胀数据库/阻塞发布队列的问题...

其中一些项目可能需要经过工作流程（如果我们通过 WebDAV 批量上传，我想我们可以为特定文件夹定义特定的磁带，从而关联不同的架构？）。但是 - 使用 WebDAV大概意味着 PDF（及其历史版本）将存储在数据库中，可能有问题。

所以...我们可以在 Tridion 中将它们链接为 external link 组件但是我认为这意味着我们不能使用 WebDAV（或者我们仍然可以使用带有外部链接 PDF 的 WebDAV - 似乎没有意义？）

我确信在 CMS 中（或周围）管理的大量二进制文件是我们许多人遇到的问题，并且很想知道其他人是如何解决这个困境的？

谢谢

Answer 1

我认为您（或您团队中的某个人）一定在 SDL Tridion 论坛中提出过这个问题。如果不是，这是一个巨大的巧合，看看那里的建议。

我会让其他人加入他们的经验，但如果您想使用 WebDAV，它将始终使用多媒体组件的上传版本。您应该将外部二进制文件视为 CMS 无法控制的只读源。

正如我在其他论坛中所说，如果您需要工作流程并管理用户权限以决定谁可以编辑二进制文件，我建议您坚持将它们上传到 CMS。如果您说的是 Terra 字节，我会更担心，但我预计您的数据大小不会有大问题。

考虑经常运行清除工具来删除非常旧版本的二进制文件，并确保在发布它们时留出一些时间。也可以小批量发布它们，因为超过 500Mb 的发布事务是众所周知的内存密集型。

Answer 2

只是为了回答你的观点：

所以...我们可以在 Tridion 中将这些链接为外部链接组件，但我 假设这意味着我们不能使用 WebDAV（或者我们仍然可以 将 WebDAV 与 externally_linked PDF 一起使用 - 似乎不会 感觉？）

我不确定 WebDAV 是否​​可行，但如果您决定采用外部多媒体路线，您可以编写一个简单的应用程序，根据 pdf 文件的存储目录创建多媒体组件。

我看到了一个实现，其中使用特定发布来允许用户放置文件并通过 Tridion 发布。发布到共享区域的出版物，即发布的共享文件夹，被映射到所需的演示网站（IIS 中的虚拟目录）......一个自定义模式字段用于帮助用户选择如何将 pdf 嵌入到内容中。我知道，这是一个非常奇怪的解决方案，但它在简单的安全性和发布配置方面解决了很多问题，并且 pdf 没有通过蓝图/本地化复制到数据库中。