<p>Craft gives you a lot of options here. I think you're close. The way I'd set it up:</p>

<ul>
<li><strong>Boats</strong> (section)</li>
<li><strong>Suppliers</strong> (section)</li>
<li><strong>Boat Type</strong> (category)</li>
</ul>

<p>Then in your boats section, set up a <code>Supplier</code> relational field, and have it relate back to your <code>suppliers</code> section and also a <code>Boat Type</code> relational field, which relates back to that category group.</p>

<p>In this way, on the front end, you can easily filter by boat type or supplier. </p>

<p><strong>Example:</strong> on your supplier pages, you can easily get a list of all the boats made by that supplier, just by querying that section like:</p>

<pre><code>{# assume we're on a supplier page #} 

{% set boatsBySupplier = craft.entries.section('boats').relatedTo(entry) %}

{% for theBoat in boatsBySupplier %}
    &lt;h2&gt;{{theBoat}}&lt;/h2&gt;
    &lt;p&gt;Model: {{theBoat.modelNumber}}&lt;/p&gt;
    ...
{% endfor %}
</code></pre>

<p>In terms of templating, there won't be a huge difference if you choose a category over an entry, for example, for your suppliers.</p>

<p>I tend to think of brands (suppliers) as content, thus content belongs in an Entry, not in a taxonomy (category). (Down the road you might want to have more than one supplier type, for example.) </p>

<p>But if your data on suppliers is relatively thin, a category would work just as well. Even then, unlike other CMS, Craft allows you to use custom fields on Categories to add more data. So there's no wrong answer there.  In that case, Craft will populate the <code>category</code> variable (and not <code>entry</code>) so just change that and you should be all good.</p>

<p>Not sure what you mean here:</p>

<blockquote>
  <p>But does it make more sense to use suppliers as entries [fields] and relate them to products as 'parents'?</p>
</blockquote>

<p>If you're asking about setting up a structure, and having the top level parent be the supplier and the boat model be a child, I'd steer clear of that.  A lot of things can go wrong with that model.</p>

<p>In general, I like to keep data structures as "flat" as possible and create depth with Craft's relationships. But if you're asking about using entries fields to relate your suppliers back to your boats, that's exactly what my example above does.</p>

CC BY-SA 3.0
2016-02-11T23:10:49.627Z
Thank you so much for the detailed response. It's good to know my brain is crafting in the right direction. On the latter 'products as parents' - that was poorly worded but intended as entries fields to suppliers. The route thru is clear now.
joomkit
CC BY-SA 3.0
2017-05-09T22:37:00.290Z
Hi @joomkit! Please consider accepting RitterKnight's answer if it was helpful.
Matt Stein
CC BY-SA 3.0
2016-02-07T22:42:17.653Z
2016-02-07T23:02:19.257Z
2016-02-07T23:02:19.257Z
RitterKnight
<p>I am going to build a boat catalog.</p>

<ul>
<li>Boat products x 40</li>
<li>Types of product x 3</li>
<li>Suppliers of products</li>
</ul>

<p>I was wondering what the best storage setup?</p>

<p>For boat and suppliers these could be entries and categories, eg:</p>

<ul>
<li>Boats = entries x 40</li>
<li>Suppliers = Categories x 9</li>
<li>Type = Categories x 3</li>
</ul>

<p>But does it make more sense to use suppliers as entries fields and relate them to products as 'parents'?</p>

<p>Are there specific template benefits later on that can help steer the decision?</p>

<entries><categories><structure><sections><craft-features>
Storage advise for product catalog
# Storage advise for product catalog

(Asked by: username_0 on 2016-02-05)

I am going to build a boat catalog.

* Boat products x 40
* Types of product x 3
* Suppliers of products

I was wondering what the best storage setup?

For boat and suppliers these could be entries and categories, eg:

* Boats = entries x 40
* Suppliers = Categories x 9
* Type = Categories x 3

But does it make more sense to use suppliers as entries fields and relate them to products as 'parents'?

Are there specific template benefits later on that can help steer the decision?

**Tags:** entries, categories, structure, sections, craft-features

---

## 1 answers

### Answer by username_1 on 2016-02-07. Score: 1 | Accepted answer

Craft gives you a lot of options here. I think you're close. The way I'd set it up:

Boats (section)
Suppliers (section)
Boat Type (category)

Then in your boats section, set up a Supplier relational field, and have it relate back to your suppliers section and also a Boat Type relational field, which relates back to that category group.
In this way, on the front end, you can easily filter by boat type or supplier. 
Example: on your supplier pages, you can easily get a list of all the boats made by that supplier, just by querying that section like:
{# assume we're on a supplier page #} 

{% set boatsBySupplier = craft.entries.section('boats').relatedTo(entry) %}

{% for theBoat in boatsBySupplier %}
    {{theBoat}}
    Model: {{theBoat.modelNumber}}
    ...
{% endfor %}

In terms of templating, there won't be a huge difference if you choose a category over an entry, for example, for your suppliers.
I tend to think of brands (suppliers) as content, thus content belongs in an Entry, not in a taxonomy (category). (Down the road you might want to have more than one supplier type, for example.) 
But if your data on suppliers is relatively thin, a category would work just as well. Even then, unlike other CMS, Craft allows you to use custom fields on Categories to add more data. So there's no wrong answer there.  In that case, Craft will populate the category variable (and not entry) so just change that and you should be all good.
Not sure what you mean here:

But does it make more sense to use suppliers as entries [fields] and relate them to products as 'parents'?

If you're asking about setting up a structure, and having the top level parent be the supplier and the boat model be a child, I'd steer clear of that.  A lot of things can go wrong with that model.
In general, I like to keep data structures as "flat" as possible and create depth with Craft's relationships. But if you're asking about using entries fields to relate your suppliers back to your boats, that's exactly what my example above does.

> **Comments:**
> **username_0**: Thank you so much for the detailed response. It's good to know my brain is crafting in the right direction. On the latter 'products as parents' - that was poorly worded but intended as entries fields to suppliers. The route thru is clear now.  
> **username_2**: Hi @joomkit! Please consider accepting RitterKnight's answer if it was helpful.  

---

