1 of 1 people found this helpful
As a side note, this Community Forum allows "Tags" per post so I am curious how these are sorted through and sent to the database structurally. Any insight on this problem is appreciated!
We toyed with the idea of having "Tag1" "Tag2" ... and then concatenating them all for sending to the website (separated by commas, for example), however this would be limited (how many Tag fields to create) as well as not user-friendly on the layout side.
Yes, that would be the worst way you could go. And don't forget that you could perform all sorts of transformations on your data before exporting it, so the output format should nor be a consideration.
The optimal solution really depends on what you have to say more about a tag association (meaning: more than just the fact that it is associated), or if you want to report on those tags.
If neither scenario applies, than using a single list field should be sufficient, rather adding a child/join table (plus, in the latter case, a Keyword table).
Will FM be the backend database for the store? Or you're looking to only manage it in FM?
If it's the second one then I'd investigate how the store's database does that and mimic that.
Having a couple of fields in a flat table like Tag1...Tag2 is the easiest to manage.
I think having too many tags and you run the risk of loosing client's focus.
Green and Silver are colors and probably should reside in a separate field named Color.
All tags in one field are also possible and searchable but if you want to group them by distinct tags then one tag per row in one to many is the option.