<p>I mostly agree with megatrond, with a few added suggestions. Since products and accessories will probably share a lot of similar fields, I recommend using the <a href="https://buildwithcraft.com/features/entry-types" rel="nofollow">Entry Type</a> feature. You can <a href="https://buildwithcraft.com/docs/templating/craft.entries#type" rel="nofollow">include or exclude entry types easily in your entry query</a>. This method might help simplify your queries, since you will only be searching against and sorting from one structure instead of two.</p>

<p>Using relations to connect accessories to products to brands to product families is a great way to organize.</p>

<ul>
<li>Products and Accessories (Structure)

<ul>
<li>Product (Entry Type)</li>
<li>Accessory (Entry Type) </li>
</ul></li>
<li>Brands (Structure)</li>
<li>Product family (Category)</li>
</ul>

CC BY-SA 3.0
2015-08-03T22:18:05.067Z
Thanks a lot Aaron and @megatrond for taking the time (even on a Sunday) and answering my questions! Taking your input into account, I´ll try this:
- Brands: Channel  
- Products: Structure with families (like iPhone, Galaxy, iPad) as 1st level and own entry type, (5s, 6 6 plus / S6, S6 edge …) as 2nd with own entry type  
- Accessories: Share almost same fields/entry types, but trying to make the relational lists as short as possible for user convenience, so another Structure  
- Product Categories: If needed I would use Categories for product categories (smartphones, tablets, cases, etc.)
Wolfram Gehring
CC BY-SA 3.0
2015-08-02T14:39:28.413Z
2015-08-02T14:39:28.413Z
Aaron Berkowitz
<p>I find it difficult sometimes to choose between a category group and a structure, so for me it mostly boils down to semantics.</p>

<p>A brand can be both a structure entry and a category. If you're going to have pages with information about the brand/product faily/product, and they will be available in some kind of menu to be browsed <em>by itself</em>, I think I'd go with a structure. If, on the other hand, they are only going to be used for filtering and organizing, a category group feels more appropriate to me.</p>

<p>From what you've described, I think I'd go with:</p>

<ul>
<li>Products (structure)</li>
<li>Accessories (structure)</li>
<li>Brands (category)</li>
<li>Product family (category)</li>
</ul>

<p>But as I said, it depends a lot on the specifics of your content.</p>

CC BY-SA 3.0
2015-07-25T19:19:29.340Z
Thanks for your input, megatrond! Choices can make life complicated ...
I had thought I would enter products and accessories in the same structure, but your idea of two structures makes it easier to handle (e.g.: product (family) listings should not include accessories, and with seperate structures I don´t have to exclude them.
One question regarding the product families: what are your reasons for putting those in categories? I would go for a structure with two levels ( family 1 > product 1.1 / product 1.2 / etc., family 2 > product 2.1 / product 2.2 / etc.) Does anything speak against this?
Wolfram Gehring
CC BY-SA 3.0
2015-08-02T16:41:41.513Z
Only downside I can think of is if a product might belong to two families, or if you want a hierarchy of product families or something.

And as I said, it depends _a lot_ on your content, so you really have to start with that and work through it to figure out what's best for you.
megatrond
CC BY-SA 3.0
2015-07-24T09:57:53.153Z
2015-07-24T09:57:53.153Z
megatrond
<p>So I am working on a project that includes an online product catalog. Is there a recommended way of setting up a catalog regarding the use of structure(s) vs. categories or a combination both? </p>

<p>I will have </p>

<ul>
<li>brands with a couple of product families and a few products in every
family</li>
<li>accessories by the same brand for the whole family </li>
<li>accessories by the same brand for various product families</li>
<li>accessories by the same brand for only certain products</li>
<li>accessories by other brands for a whole product family </li>
<li>accessories by other brands for a certain product only</li>
</ul>

<p>Wondering if one structure or two (for brands and products) and relations would work and be efficient and flexible, or if I should work with categories as well? In total, it will be about 100 to 150 items in the catalog.</p>

<p>Thanks for opinions!</p>

<categories><sections>
Structure(s) vs. Categories for product catalog
# Structure(s) vs. Categories for product catalog

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

So I am working on a project that includes an online product catalog. Is there a recommended way of setting up a catalog regarding the use of structure(s) vs. categories or a combination both?

I will have

* brands with a couple of product families and a few products in every
  family
* accessories by the same brand for the whole family
* accessories by the same brand for various product families
* accessories by the same brand for only certain products
* accessories by other brands for a whole product family
* accessories by other brands for a certain product only

Wondering if one structure or two (for brands and products) and relations would work and be efficient and flexible, or if I should work with categories as well? In total, it will be about 100 to 150 items in the catalog.

Thanks for opinions!

**Tags:** categories, sections

---

## 2 answers

### Answer by username_1 on 2015-08-02. Score: 2

I mostly agree with megatrond, with a few added suggestions. Since products and accessories will probably share a lot of similar fields, I recommend using the [Entry Type](https://buildwithcraft.com/features/entry-types) feature. You can [include or exclude entry types easily in your entry query](https://buildwithcraft.com/docs/templating/craft.entries#type). This method might help simplify your queries, since you will only be searching against and sorting from one structure instead of two.

Using relations to connect accessories to products to brands to product families is a great way to organize.

* Products and Accessories (Structure)
  + Product (Entry Type)
  + Accessory (Entry Type)
* Brands (Structure)
* Product family (Category)

> **Comments:**
> **username_0**: Thanks a lot Aaron and @megatrond for taking the time (even on a Sunday) and answering my questions! Taking your input into account, I´ll try this: - Brands: Channel   - Products: Structure with families (like iPhone, Galaxy, iPad) as 1st level and own entry type, (5s, 6 6 plus / S6, S6 edge …) as 2nd with own entry type   - Accessories: Share almost same fields/entry types, but trying to make the relational lists as short as possible for user convenience, so another Structure   - Product Categories: If needed I would use Categories for product categories (smartphones, tablets, cases, etc.)  

---

### Answer by username_2 on 2015-07-24. Score: 2

I find it difficult sometimes to choose between a category group and a structure, so for me it mostly boils down to semantics.

A brand can be both a structure entry and a category. If you're going to have pages with information about the brand/product faily/product, and they will be available in some kind of menu to be browsed *by itself*, I think I'd go with a structure. If, on the other hand, they are only going to be used for filtering and organizing, a category group feels more appropriate to me.

From what you've described, I think I'd go with:

* Products (structure)
* Accessories (structure)
* Brands (category)
* Product family (category)

But as I said, it depends a lot on the specifics of your content.

> **Comments:**
> **username_0**: Thanks for your input, megatrond! Choices can make life complicated ... I had thought I would enter products and accessories in the same structure, but your idea of two structures makes it easier to handle (e.g.: product (family) listings should not include accessories, and with seperate structures I don´t have to exclude them. One question regarding the product families: what are your reasons for putting those in categories? I would go for a structure with two levels ( family 1 > product 1.1 / product 1.2 / etc., family 2 > product 2.1 / product 2.2 / etc.) Does anything speak against this?  
> **username_2**: Only downside I can think of is if a product might belong to two families, or if you want a hierarchy of product families or something.  And as I said, it depends _a lot_ on your content, so you really have to start with that and work through it to figure out what's best for you.  

---

