<p>There really isn't a "proper/best practice" that fits all situations. Any determination will depend on the complexity of the data, and what you plan to do with it (both now and in the future).</p>

<p>For example:</p>

<ul>
<li><p>If the data is simple (i.e. text or other simple field type), likely to be unique or one-offs, not linked to anything else, only 1 level deep, and only a few data points, then you might consider using a simple "table" field.</p></li>
<li><p>If the data is more complex (i.e. more than 1 level, anything other than text or other simple data type, or more than a few data points), then consider a 'matrix' or 'super-table' (plugin) field; or, if relational in any way, use a 'categories', 'entries', or 'users' field (depending on other considerations).</p></li>
<li><p>If you want to limit the input to predefined options, or the data is used more than once (i.e. the same author writes several articles) then you might consider an 'entries' or 'users' field (as, among other things, it normalizes the data and prevents entry errors).</p></li>
<li><p>Likewise, if you ever plan on providing an alternate display of the data (i.e. display all articles by author 'Jane Doe'), then you might consider an 'entries' or 'users' field.</p></li>
<li><p>If the 'authors' have anything to do with access to the system (i.e. at some point we want 'authors' to able to log-in and update their own data, etc) then you would likely want a 'users' field; otherwise an 'entries' field might be better (as it will have less overhead/entry requirements).</p></li>
<li><p>If there is no compelling reason to use an 'entries', 'categories' or 'users' field (i.e. the data is unique and does not need to be relational), but the data is still complex or has many data points, then a 'matrix' field is a good option, because it's a bit easier to view, edit and manage (i.e. you don't need to double click to edit; all data is visible; you can enable/disable matrix blocks; etc, etc).</p></li>
</ul>

<p>These are just a few considerations, but I think that you get the point that it really depends on the use/context.</p>

<p>For this use-case, for 'authors', I would likely opt to use an 'entries' field and set up a separate section for 'authors' (or a 'users' field if I thought that 'authors' might ever have anything to do with login, access, or 'ownership' of the entry). Otherwise, I might go with a simple 'table' field, if I knew that each author is a one-off and I will never want to search, link to, or otherwise display data by author.</p>

CC BY-SA 4.0
2020-01-24T22:01:49.133Z
Huge thank you, this is exactly the information I was looking for. Hope this is helpful for others working on "schema design" in the future.
Graham Bewley
CC BY-SA 4.0
2020-01-24T21:55:11.047Z
2020-01-24T21:55:11.047Z
Douglas McDonald
<p>Probably you would want to use:</p>

<ul>
<li><a href="https://docs.craftcms.com/v3/users-fields.html" rel="nofollow noreferrer">Users field</a> as a relation to one or more of the users</li>
<li><a href="https://docs.craftcms.com/v3/categories-fields.html" rel="nofollow noreferrer">Categories field</a> as a relation to one or more of the categories</li>
</ul>

CC BY-SA 4.0
2020-01-23T13:28:45.730Z
thank you for the response. Would the recommendation to use a User field still apply if I will potentially have thousands of entries all with different "Authors"? The end goal is to collect data from a great number of sources. And what about the case where there are multiple authors, like above?
Graham Bewley
CC BY-SA 4.0
2020-01-23T21:33:06.117Z
If I'm understanding you correctly, then yes.
andrew.welch
CC BY-SA 4.0
2020-01-24T00:50:37.553Z
I think the larger question I have is what to do with arrays of objects in general. What about a case where the array of objects is something other than a person.

Let's say this "news article" entry required an array of citations, each of which included a person's name, citation name, a URL, and date of publishing. This makes the case for using the User field less convincing to me, no? Thank you so much for your help
Graham Bewley
CC BY-SA 4.0
2020-01-23T13:13:25.443Z
2020-01-23T13:13:25.443Z
andrew.welch
<p>I'm using Craft CMS for the first time and have a question about the proper/best practice to store what would equate to an array of objects (or just a plain array) in Javascript or JSON.</p>

<p>Say I'd like to store a number of entries with the following shape :</p>

<pre><code>{
    newspaper: 'New York Times',
    article: 'How to Write Web Apps Without Help From Stack Overflow',
    authors: [
        {
            name: 'John Doe',
            title: 'Staff Writer'
        },
        {
            name: 'Jane Smith',
            title: 'Editor'
        }
    ],
    categories: [ 'technology', 'web' ]
}
</code></pre>

<p>I understand that I store the first two properties as "Plain Text" fields, but I am confused on the proper way to store the authors and categories arrays as Fields. It looks like I would use a Matrix Field for this, but in the demo I'm referencing, they use Matrix fields in a slightly different way.</p>

<p>Just looking for validation that I should use matrix fields in this case, or some direction otherwise.</p>

<craft3><matrix><fieldtypes>
Proper way to implement array of objects as Craft field
# Proper way to implement array of objects as Craft field

(Asked by: username_0 on 2020-01-23)

I'm using Craft CMS for the first time and have a question about the proper/best practice to store what would equate to an array of objects (or just a plain array) in Javascript or JSON.
Say I'd like to store a number of entries with the following shape :
{
    newspaper: 'New York Times',
    article: 'How to Write Web Apps Without Help From Stack Overflow',
    authors: [
        {
            name: 'John Doe',
            title: 'Staff Writer'
        },
        {
            name: 'Jane Smith',
            title: 'Editor'
        }
    ],
    categories: [ 'technology', 'web' ]
}

I understand that I store the first two properties as "Plain Text" fields, but I am confused on the proper way to store the authors and categories arrays as Fields. It looks like I would use a Matrix Field for this, but in the demo I'm referencing, they use Matrix fields in a slightly different way.
Just looking for validation that I should use matrix fields in this case, or some direction otherwise.

**Tags:** craft3, matrix, fieldtypes

---

## 2 answers

### Answer by username_1 on 2020-01-24. Score: 1 | Accepted answer

There really isn't a "proper/best practice" that fits all situations. Any determination will depend on the complexity of the data, and what you plan to do with it (both now and in the future).

For example:

* If the data is simple (i.e. text or other simple field type), likely to be unique or one-offs, not linked to anything else, only 1 level deep, and only a few data points, then you might consider using a simple "table" field.
* If the data is more complex (i.e. more than 1 level, anything other than text or other simple data type, or more than a few data points), then consider a 'matrix' or 'super-table' (plugin) field; or, if relational in any way, use a 'categories', 'entries', or 'users' field (depending on other considerations).
* If you want to limit the input to predefined options, or the data is used more than once (i.e. the same author writes several articles) then you might consider an 'entries' or 'users' field (as, among other things, it normalizes the data and prevents entry errors).
* Likewise, if you ever plan on providing an alternate display of the data (i.e. display all articles by author 'Jane Doe'), then you might consider an 'entries' or 'users' field.
* If the 'authors' have anything to do with access to the system (i.e. at some point we want 'authors' to able to log-in and update their own data, etc) then you would likely want a 'users' field; otherwise an 'entries' field might be better (as it will have less overhead/entry requirements).
* If there is no compelling reason to use an 'entries', 'categories' or 'users' field (i.e. the data is unique and does not need to be relational), but the data is still complex or has many data points, then a 'matrix' field is a good option, because it's a bit easier to view, edit and manage (i.e. you don't need to double click to edit; all data is visible; you can enable/disable matrix blocks; etc, etc).

These are just a few considerations, but I think that you get the point that it really depends on the use/context.

For this use-case, for 'authors', I would likely opt to use an 'entries' field and set up a separate section for 'authors' (or a 'users' field if I thought that 'authors' might ever have anything to do with login, access, or 'ownership' of the entry). Otherwise, I might go with a simple 'table' field, if I knew that each author is a one-off and I will never want to search, link to, or otherwise display data by author.

> **Comments:**
> **username_0**: Huge thank you, this is exactly the information I was looking for. Hope this is helpful for others working on "schema design" in the future.  

---

### Answer by username_2 on 2020-01-23. Score: 1

Probably you would want to use:

* [Users field](https://docs.craftcms.com/v3/users-fields.html) as a relation to one or more of the users
* [Categories field](https://docs.craftcms.com/v3/categories-fields.html) as a relation to one or more of the categories

> **Comments:**
> **username_0**: thank you for the response. Would the recommendation to use a User field still apply if I will potentially have thousands of entries all with different "Authors"? The end goal is to collect data from a great number of sources. And what about the case where there are multiple authors, like above?  
> **username_2**: If I'm understanding you correctly, then yes.  
> **username_0**: I think the larger question I have is what to do with arrays of objects in general. What about a case where the array of objects is something other than a person.  Let's say this "news article" entry required an array of citations, each of which included a person's name, citation name, a URL, and date of publishing. This makes the case for using the User field less convincing to me, no? Thank you so much for your help  

---

