Best Practice (1 Viewer)

JoeyJoystick

Registered User.
Local time
Today, 14:14
Joined
Jul 23, 2015
Messages
15
Hi All,

I am wondering if someone can get some light on the following.

What is best practice for the following.

When you make a database with manufacturers and products and want to add tags to these products. Tags to identify and help searching the products. example for cars. You want to add tags that identify whether the car is diesel, electric or petrol. You also want to add a tag to show whether it is a sedan, hatchback, SUV, pickup. and of course you want to say something about the power. 50-100hp, 100-200hp, 200-300hp, 300-500hp and 500+hp.

For what I am doing I can easily think of 20 main categories of tags that I need to select from and in many case multiple tags would need to be added. In addition to this these tags would have even more subcategories and these may have subcategories as well.

I do think it would make sense to add main categories to manufacturers to identify in which field(s) they are active, but I guess you would ultimately want to identify each product individually with tags. These are, of course, 2 different tables.

Doing this with multiple values in a field just doesn't sound right to me. Adding 20 fields somehow doesn't sound right either. All doable, but just sounds like it will cause a lot of trouble in the long run.

You can clearly see something similar in the way Amazon does this on their website with there product categories. what you see here is that you can get the same products in your search results even though you have selected (searched for) different criteria (tags).

Any thoughts on the scenario?

Joost (Joey)
 

Ranman256

Well-known member
Local time
Today, 08:14
Joined
Apr 9, 2015
Messages
4,339
No, I think a single car would only have 1 tag of HP.
But it can have many tags of various properties.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 13:14
Joined
Feb 19, 2013
Messages
16,610
suggest your product 'tags' are additional fields in your product table, each with its own list of options

e.g.
fuel - petrol/diesel/lpg/electric
bodyshape - sedan/hatchback/pickup
BHP - could be a number

etc

these can then be populated individually using a combobox where required.

You can either store petrol/sedan etc in separate lookup tables, one for each 'type', or a single table which includes a 'type' column

I do some work for a motor components manufacturer who have their data like this. WARNING -this is a wide image which widens your browser - scroll to the right to see the apparently missing header

 

Attachments

  • Capture.JPG
    Capture.JPG
    49.4 KB · Views: 294

JoeyJoystick

Registered User.
Local time
Today, 14:14
Joined
Jul 23, 2015
Messages
15
Hi CJ,

Thanks a lot for your response. Good guidance in the right direction.

Would you make lists yourself when making combos or pull it from an other table. I like the idea of pulling it from an other table. I think pulling it from a table will allows for greater flexibility in the future but is more work. Makeing lists with combo's is easier, but harder to maintain later on I guess.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 13:14
Joined
Feb 19, 2013
Messages
16,610
depends - for a short list that won't change you could use a valuelist, for longer lists or where it can be added to I would use a table. My personal choice is a single table providing all values are the same datatype
 

Users who are viewing this thread

Top Bottom