<p>It's not about performance or best practices, it's about your content structure. If you create one matrix field with two block types, both block types will be available everywhere that matrix field is used. So the question you have to ask is whether it makes sense to mix and match the different block types. On the other hand, if you use separate matrix fields, editors <em>won't</em> be able to have a mixture of both block types, even if you add both fields to a field layout.</p>
<p>Let's say you're working on a matrix field for the content of a blog entry. A blog entry consists of text, images, code examples, and statements. It makes sense two have those four block types in a single matrix field, since users need to be able to mix and match those block types in arbitrary arrangements and combine multiples of each blocks.</p>
<blockquote>
<p>For example, to implement a slider, there should be image and caption block types inside a slider matrix.</p>
</blockquote>
<p>Not really, unless I'm misunderstanding the example. A single carousel slide could have both an image and a caption, so you should create one block type <code>slide</code> with fields for the image and caption. You would only create different block types if you want to have different types of slides – for example, a slide with <em>only</em> an image or <em>only</em> some text content.</p>
<blockquote>
<p>I remember i read in documentation something like reconsidering data structure when there are to many matrix fields which i can't find anymore.</p>
</blockquote>
<p>There's a limit to how many matrix block types and fields are feasible, both from a technical and UX standpoint. If you notice you have too many block types and nested fields, it can make sense to use sections and entries instead. Instead of putting everything inside a single gigantic matrix field, separate out pieces of content as individual entries and use <a href="https://craftcms.com/docs/4.x/entries-fields.html" rel="nofollow noreferrer">entries fields</a> to relate them to each other.</p>
<p>Here's a good talk from Dot All 2022 on that approach:</p>
<p><a href="https://craftcms.com/events/dot-all-2022/sessions/using-entries-and-relationships-as-a-content-builder-system" rel="nofollow noreferrer">https://craftcms.com/events/dot-all-2022/sessions/using-entries-and-relationships-as-a-content-builder-system</a></p>

CC BY-SA 4.0
2023-07-24T15:55:00.413Z
2023-07-24T15:55:00.413Z
MoritzLost
<p>I am aware that block types that are related should have a matrix shared. For example, to implement a slider, there should be image and caption block types inside a slider matrix.</p>
<p>But what about unrelated block types? Do these unrelated block types need to have different matrix fields (from performance, UX, best practice point of view)?</p>
<p>I remember i read in documentation something like reconsidering data structure when there are to many matrix fields which i can't find anymore.</p>

CC BY-SA 4.0
2023-07-23T16:05:37.190Z
I don't quite understand your problem, I think because it's pretty theoretical. Do you have a specific use-case that you're thinking about, or a specific problem you're trying to solve?
MoritzLost
CC BY-SA 4.0
2023-07-23T19:21:57.030Z
Thanks. i give you an example. Imagine i have only two block types. the data stored in these block types/blocks are not related at all. do you put these block types inside one matrix field or two matrices? What Craft CMS recommends in this situation? also the number of these block types should affects if i use one matrix or more?
user9975
<matrix><block-types>
Can not-related block types share a matrix field
# Can not-related block types share a matrix field

(Asked by: username_0 on 2023-07-23)

I am aware that block types that are related should have a matrix shared. For example, to implement a slider, there should be image and caption block types inside a slider matrix.

But what about unrelated block types? Do these unrelated block types need to have different matrix fields (from performance, UX, best practice point of view)?

I remember i read in documentation something like reconsidering data structure when there are to many matrix fields which i can't find anymore.

**Tags:** matrix, block-types
> **Comments:**
> **username_1**: I don't quite understand your problem, I think because it's pretty theoretical. Do you have a specific use-case that you're thinking about, or a specific problem you're trying to solve?  
> **username_0**: Thanks. i give you an example. Imagine i have only two block types. the data stored in these block types/blocks are not related at all. do you put these block types inside one matrix field or two matrices? What Craft CMS recommends in this situation? also the number of these block types should affects if i use one matrix or more?  

---

## 1 answers

### Answer by username_1 on 2023-07-24. Score: 1 | Accepted answer

It's not about performance or best practices, it's about your content structure. If you create one matrix field with two block types, both block types will be available everywhere that matrix field is used. So the question you have to ask is whether it makes sense to mix and match the different block types. On the other hand, if you use separate matrix fields, editors *won't* be able to have a mixture of both block types, even if you add both fields to a field layout.

Let's say you're working on a matrix field for the content of a blog entry. A blog entry consists of text, images, code examples, and statements. It makes sense two have those four block types in a single matrix field, since users need to be able to mix and match those block types in arbitrary arrangements and combine multiples of each blocks.

> For example, to implement a slider, there should be image and caption block types inside a slider matrix.

Not really, unless I'm misunderstanding the example. A single carousel slide could have both an image and a caption, so you should create one block type `slide` with fields for the image and caption. You would only create different block types if you want to have different types of slides – for example, a slide with *only* an image or *only* some text content.

> I remember i read in documentation something like reconsidering data structure when there are to many matrix fields which i can't find anymore.

There's a limit to how many matrix block types and fields are feasible, both from a technical and UX standpoint. If you notice you have too many block types and nested fields, it can make sense to use sections and entries instead. Instead of putting everything inside a single gigantic matrix field, separate out pieces of content as individual entries and use [entries fields](https://craftcms.com/docs/4.x/entries-fields.html) to relate them to each other.

Here's a good talk from Dot All 2022 on that approach:

<https://craftcms.com/events/dot-all-2022/sessions/using-entries-and-relationships-as-a-content-builder-system>


---

