The use and non-use of ID fields

The use of ID fields in import files often gives many users problems, whether this is due to not reading the documentation or expecting different behaviour from CSV Improved is not the question I want to answer here. What I do want to hightlight is the problems that might occur using ID fields.

What is an ID field?

An ID field is a field that holds a unique reference number for data in the database. Examples of ID fields are:

• product_id: Holds the ID for a product
• manufacturer_id: Holds the ID for a manufacturer
• category_id: Holds the ID for a category
• etc.

What is the life expectancy of an ID field?

The life expectancy of an ID field can range from days to years. As long as the data does not get deleted from the database the ID stays the same. Regularly deleting and importing new data makes the ID change as often as this process is repeated.

How important is the ID field?

As mentioned earlier, the ID field is unique. This makes it important however not as important as other fields that are more consistent than the ID field. Some examples of more important fields:

• product_sku: The Stock Keeping Unit will almost never change as it identifies a specific product
• manufacturer_name: The name of a manufacturer is also unlikely to change
• category_path: The name of a category is unlikely to change
  

Even though the ID field is important to the shop, other fields are more important for import.

Which field should I use?

It is advised not to use ID fields for import. CSV Improved will find the correct ID based on the other fields you import. If an ID is ever changed and you don't know about it, the import will go wrong.

Another example is when you are importing new data, the ID field does not exist and nothing will be imported as the database cannot find the ID and your shop will remain empty.

Final words

Be cautious using ID fields in your import file, imports are more likely to succeed not using these fields.