<p>I would set an <a href="https://docs.craftcms.com/v3/sections-and-entries.html#entry-types" rel="nofollow noreferrer">dynamic title</a> for entry titles ie. <code>{make.one().title} - {model}</code>, then have <strong>make</strong> as a category field, <strong>model</strong> as a text field.</p>

<p>It doesn't sound like it matters what the entry title is, but this will make it nicer to manage in the back-end.</p>

CC BY-SA 4.0
2020-02-21T09:46:52.150Z
2020-02-21T09:46:52.150Z
dmatthams
<p>The nested/hierarchical presentation you're suggesting is perfectly fine for the front end presentation, but you don't want to permanently store your data that way in the back end as it's too rigid and doesn't reflect the fundamental content data model, which in turn makes everything you want to do with the data (such as filtering/searching/sorting) a bit harder.</p>

<p>I'm sure there are lots of different approaches, but for maximum flexibility, if it were me, I would run a few imports consecutively:</p>

<ol>
<li>Import all the "Makes" into a dedicated section</li>
<li>Import all the "Countries" into a dedicated category group or section (bear in mind that categories as a concept is rumoured to be going away in Craft 4).</li>
</ol>

<p>...these first two steps give your editors the flexibility to add/edit/remove Makes and Countries in future - do the same with any other columns you think should be treated that way... the decision would depend on how many items you expect there to be, how often they might require editing, whether they should be searchable/filterable, and to what extent the data should be arbitrary or pre-defined. (For example, the CC rating could be imported into another category group or a simple dropdown field of pre-defined values, whereas the 'Act CC' (Actual CC?) rating would more likely be a plain text field to cater for any arbitrary value).</p>

<ol start="3">
<li>Import everything else into a dedicated section (maybe called "Products", or "Chains" - Again, "Products" would give you more future flexibility, but you might want to then pre-categorise everything in this import under a new "Chains" category). Use the Model as the title, and create relationships to the Makes and Countries (and whatever other relationships you need). You'd need to decide what fieldtypes to use for the other columns - generally you're best avoiding plain text fields for something like this to maintain future data integrity and make front end searching/filtering consistent.</li>
</ol>

<p>This is all just fundamental content modelling - It really comes down to how small you want to break things up. Most content modellers err on the side of using highly atomic content and then creating relationships between them, but you can take that concept too far.</p>

CC BY-SA 4.0
2020-02-20T15:55:52.357Z
Thanks James,  We're actually thinking of putting this out to Freelance as I can't get my head around it and we need to prove concept before client will move onto the next stage.
Martin
CC BY-SA 4.0
2020-02-20T15:22:26.210Z
2020-02-20T15:22:26.210Z
James Smith
<p>I have a sample CSV to test bulk import is feasible before we try it with the real CSV which contains 12000 items.
<a href="https://i.sstatic.net/3PLE0.gif" rel="nofollow noreferrer"><img src="https://i.sstatic.net/3PLE0.gif" alt="example of the test csv file"></a></p>

<p>I've imported the sample using FeedMe but the only unique identifier is 'Model'.  This results in many duplicate titles because FeedMe just iterates over the rows.</p>

<p>Ideally we want some kind of categorisation where a 'Make is defined and then all other 'make' references are nested under the first...</p>

<ul>
<li><p><strong>AC Petite</strong> </p>

<ul>
<li><strong><em>346</em></strong> -- CC, Country, Year etc</li>
<li><strong><em>353</em></strong> -- CC, Country, Year etc</li>
</ul></li>
<li><p><strong>Adler</strong> </p>

<ul>
<li><strong><em>M100</em></strong> -- CC, Country, Year etc</li>
<li><strong><em>MR100</em></strong> -- CC, Country, Year etc</li>
<li><strong><em>M150</em></strong> -- CC, Country, Year etc</li>
<li><strong><em>MB150</em></strong> -- CC, Country, Year etc</li>
</ul></li>
</ul>

<p>etc...</p>

<p>Ultimately we're trying to create a "Motorbike Chain Finder".  Where a user will:
1. Select their Make (AC Petite, Adler, Triumph etc...)
2. Select their Model or their CC</p>

<p>The process will then display the chain type (pitch) which will fit their bike.</p>

<p>I'm looking for help/guidance on the best way to set up Craft (Section/Fields) so the imported data can be queried as described above.</p>

<p>For example, is there a way to auto categorise based on 'Make' or is there a way to maybe do this after the initial import?</p>

<p>I'm not even sure i'm asking the question correctly but any help is appreciated.</p>

CC BY-SA 4.0
2020-02-20T12:55:29.297Z
You could import all of the *Makes* as categories first, then attach that category when you import all of the *Models*.
Joshua M
CC BY-SA 4.0
2020-02-20T15:16:44.423Z
Thanks Joshua M but I don't understand what you mean?  As you suggest I have re-imported and created new categories using the 'Make' column.   I then created a Category field attached to my Category Group and added it to the Entry Type. I then created a new Feed (same csv) to import the Models as Entries but the Category Field is not available to map to?
Martin
<plugin-feedme>
FeedMe Import CSV
# FeedMe Import CSV

(Asked by: username_0 on 2020-02-20)

I have a sample CSV to test bulk import is feasible before we try it with the real CSV which contains 12000 items.
[![example of the test csv file](https://i.sstatic.net/3PLE0.gif)](https://i.sstatic.net/3PLE0.gif)

I've imported the sample using FeedMe but the only unique identifier is 'Model'. This results in many duplicate titles because FeedMe just iterates over the rows.

Ideally we want some kind of categorisation where a 'Make is defined and then all other 'make' references are nested under the first...

* **AC Petite**

  + ***346*** -- CC, Country, Year etc
  + ***353*** -- CC, Country, Year etc
* **Adler**

  + ***M100*** -- CC, Country, Year etc
  + ***MR100*** -- CC, Country, Year etc
  + ***M150*** -- CC, Country, Year etc
  + ***MB150*** -- CC, Country, Year etc

etc...

Ultimately we're trying to create a "Motorbike Chain Finder". Where a user will:
1. Select their Make (AC Petite, Adler, Triumph etc...)
2. Select their Model or their CC

The process will then display the chain type (pitch) which will fit their bike.

I'm looking for help/guidance on the best way to set up Craft (Section/Fields) so the imported data can be queried as described above.

For example, is there a way to auto categorise based on 'Make' or is there a way to maybe do this after the initial import?

I'm not even sure i'm asking the question correctly but any help is appreciated.

**Tags:** plugin-feedme

> **Comments:**
> **username_1**: You could import all of the *Makes* as categories first, then attach that category when you import all of the *Models*.  
> **username_0**: Thanks username_1 but I don't understand what you mean?  As you suggest I have re-imported and created new categories using the 'Make' column.   I then created a Category field attached to my Category Group and added it to the Entry Type. I then created a new Feed (same csv) to import the Models as Entries but the Category Field is not available to map to?  

---

## 2 answers

### Answer by username_2 on 2020-02-21. Score: 1

I would set an [dynamic title](https://docs.craftcms.com/v3/sections-and-entries.html#entry-types) for entry titles ie. `{make.one().title} - {model}`, then have **make** as a category field, **model** as a text field.

It doesn't sound like it matters what the entry title is, but this will make it nicer to manage in the back-end.


---

### Answer by username_3 on 2020-02-20. Score: 1

The nested/hierarchical presentation you're suggesting is perfectly fine for the front end presentation, but you don't want to permanently store your data that way in the back end as it's too rigid and doesn't reflect the fundamental content data model, which in turn makes everything you want to do with the data (such as filtering/searching/sorting) a bit harder.

I'm sure there are lots of different approaches, but for maximum flexibility, if it were me, I would run a few imports consecutively:

1. Import all the "Makes" into a dedicated section
2. Import all the "Countries" into a dedicated category group or section (bear in mind that categories as a concept is rumoured to be going away in Craft 4).

...these first two steps give your editors the flexibility to add/edit/remove Makes and Countries in future - do the same with any other columns you think should be treated that way... the decision would depend on how many items you expect there to be, how often they might require editing, whether they should be searchable/filterable, and to what extent the data should be arbitrary or pre-defined. (For example, the CC rating could be imported into another category group or a simple dropdown field of pre-defined values, whereas the 'Act CC' (Actual CC?) rating would more likely be a plain text field to cater for any arbitrary value).

3. Import everything else into a dedicated section (maybe called "Products", or "Chains" - Again, "Products" would give you more future flexibility, but you might want to then pre-categorise everything in this import under a new "Chains" category). Use the Model as the title, and create relationships to the Makes and Countries (and whatever other relationships you need). You'd need to decide what fieldtypes to use for the other columns - generally you're best avoiding plain text fields for something like this to maintain future data integrity and make front end searching/filtering consistent.

This is all just fundamental content modelling - It really comes down to how small you want to break things up. Most content modellers err on the side of using highly atomic content and then creating relationships between them, but you can take that concept too far.

> **Comments:**
> **username_0**: Thanks James,  We're actually thinking of putting this out to Freelance as I can't get my head around it and we need to prove concept before client will move onto the next stage.  

---

