TYPO3 避免在中間表中存儲數據時的后端工作流程

Question

我有ExtbaseFluid書中描述的情況：
我想將信息存儲在根本不推薦的中間表中。

這是上述鏈接書章節的警告框中的引用：

不要將數據存儲在與域有關的中間表中。 盡管 TYPO3 支持這一點（尤其是與內聯關系記錄編輯 (IRRE) 結合使用），但這始終表明可以對您的域 Model 進行進一步改進。中間表是並且應該始終是存儲關系的工具，僅此而已。

假設您要存儲一張 CD 及其包含的音樂曲目： CD -- m:n (Intermediate Table) -- Song 。 軌道號可以存儲在中間表的字段中。 但是，軌道應該存儲為一個單獨的域 object，連接實現為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. 打開cd記錄時，編輯器無法直接訪問song ？
   相反，她/他首先必須打開track記錄，然后才能從那里導航到song ？
3. 將數據存儲在中間表中真的有那么糟糕嗎？ TYPO3 表sys_file_reference也一樣？？ 但我想知道如何顯示這些數據（因為 IRRE 是不可能的，因為它只能用於1:n關系（ source ）。

Answer 1

您必須問自己的問題是：我是想按書本進行編碼，還是想創建一種實用的方法來解決客戶的問題？

在這個特定的案例中，額外的問題是，最初發明 Extbase 的人有一個相當復雜和學術的方法，但是當涉及到實用的使用和性能時，他們被自己的規則所阻礙，並被書本編碼所束縛。

尤其是這個示例和警告消息顯示了一種思維方式，這也是為什么我從未真正使用過 Extbase而是使用 Core-API 方法來創建高性能和實用的查詢以獲得所需的結果集的原因之一。 現在我們已經在引擎蓋下得到了Doctrine ，即使具有非常異國情調的 DB 風味，它也像一個魅力。

當然intermediate tables是一個好主意，當然這些intermediate tables可以而且應該用額外的數據字段來豐富，不需要第 3、4 或第 n 個表來存儲即一組簡單的下拉選項，因為這很容易使用TCA中配置的attributes進行處理，如下所示： https://docs.typo3.org/m/typo3/reference-tca/master/en-us/ColumnsConfig/Type/Inline/Examples.ZFC235FDC73A8D226

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-mn-relations

Answer 2

取決於問題，有時中間表是一個實體，有時不是。 在此示例中，中間表是軌道，其中包含：[uid, cd, song, track_no, ...（定義軌道所需的任何其他內容）]

定義數據時要小心，不要讓它太高級。