避免将数据存储在中间表中时的 TYPO3 后端工作流

问题描述

我遇到了 ExtbaseFluid 书中描述的情况:
我想将信息存储在中间表中,完全不推荐。

这是上面链接书籍章节警告框中的引用:

不要将数据存储在与域相关的中间表中。尽管 TYPO3 支持这一点(特别是与内联关系记录编辑 (IRRE) 结合使用,但这始终表明可以对域模型进行进一步改进。中间表​​是并且应该始终是存储关系的工具,而不是其他任何东西。

假设您要存储包含音乐曲目的 CD:CD -- m:n (Intermediate Table) -- Song。轨道号可以存储在中间表的字段中。但是,轨道应该存储为一个单独的域对象,连接实现为CD -- 1:n -- Track -- n:1 -- Song

所以我不想做不推荐的事情。但是考虑到推荐解决方案的结果的编辑器的工作流程对我来说产生了一些问题。

为了继续这个例子,我需要以下表格:

tx_extname_domain_model_cd
tx_extname_domain_model_cd_track_mm
tx_extname_domain_model_track (which holds the track number)
tx_extname_domain_model_track_song_mm
tx_extname_domain_model_song

据我所知,这将导致编辑器需要创建以下记录:

  • cd 的一条记录
  • song 的一条记录
  • 现在编辑器可以为 track 创建一个记录。
    在那里添加了曲目编号。
    此外,需要分配 cd 记录以及 song


以下是我的问题:

  1. 我猜这个工作流程不能通过一些(我不知道的)TCA 设置来改进?
  2. 编辑器在打开 song 记录时无法直接到达 cd
    相反,她/他必须先打开 track 记录,然后才能从那里导航到 song?
  3. 将数据存储在中间表中真的有那么糟糕吗? TYPO3 表 sys_file_reference 也是如此!?但我想知道如何显示这些数据(因为 IRRE 是不可能的,因为它只能用于 1:n 关系 (source)。

解决方法

您必须问自己的问题是:我是想按照书本编写代码,还是想创建一种务实的方法来解决客户的问题?

在这个特定案例中,额外的问题是,最初发明 Extbase 的人有一种非常复杂和学术的方法,但是当涉及到实用的使用和性能时,他们被自己的规则所阻碍,并坚持编码书。

特别是这个例子和警告消息显示了一种思考方式,这是原因之一,为什么我从来没有真正使用过 Extbase,而是使用 Core-API 方法来创建高性能和实用的查询以获得所需的结果集。现在我们已经了解了 Doctrine,即使使用非常奇特的 DB 风格,这也很有魅力。

当然 intermediate tables 是个好主意,当然那些 intermediate tables 可以而且应该用额外的数据字段来丰富,这些字段不需要需要第 3 个、第 4 个或第 n 个表来存储即一组简单的下拉选项,因为这可以通过在 attributes 中配置的 TCA 轻松处理,如下所示:https://docs.typo3.org/m/typo3/reference-tca/master/en-us/ColumnsConfig/Type/Inline/Examples.html

sys_file_reference 是最突出的例子,因为它提供的正是那种不应该被注入到附加表中的附加信息 - 猜猜是什么,TYPO3 核心不使用一行用于处理该数据或核心表的几乎任何其他数据的 Extbase 代码。

要回答您的最后一个问题:查看旧的 IRRE 教程以了解如何使用中间内联表进行 m:n 连接。 https://docs.typo3.org/typo3cms/extensions/irre_tutorial/0.4.0/Manual/Index.html#intermediate-tables-for-m-n-relations

,

取决于问题,有时中间表是一个实体,有时不是。在这个例子中,中间表是轨道,其中将包含:[uid,cd,song,track_no,...(定义轨道所需的任何其他内容)]

定义数据时要小心,不要让它太高级。