Best practice for Tags

Question

Hello,
In packaged applications Tags are used in most of the Apps. Eg. in Customer Tracker App, we can add tags to a customer where these tags are stored in a varchr2 column in the Customers Table.
In my case, I have predefined tags for Properties (Real Estate) in a lookup table called TAGS . Eg, Full floor, Furnished, Fitted, Duplex, Attached... What is the best Practice to tag the properties:
1- To store these tags in a varchar column in PROPERTIES table using Shuttle box.
OR
2- To store them in a third table Eg, PROPERTIES_TAGS (ID PK, PROPERTY_ID FK , TAG_ID FK ), Then use LISTAGG function to show the tags in one line in the Properties Report.
OR
Do you have a better option ??
Regards,
Fateh

Answer 1

Fateh wrote:
Hello,
In packaged applications Tags are used in most of the Apps. Eg. in Customer Tracker App, we can add tags to a customer where these tags are stored in a varchr2 column in the Customers Table.
In my case, I have predefined tags for Properties (Real Estate) in a lookup table called TAGS . Eg, Full floor, Furnished, Fitted, Duplex, Attached...These appear to me to be two different use cases. In the packaged applications the tags allow end users to attach free-form metadata to data for their own purposes (these are sometimes called "folk taxonomies"). Users may use tags for different purposes, or different tags for the same purpose. For example, I might add "Monday", "Thursday" or "Friday" tags to customers because those are the days they receive their deliveries. For the same purpose you might tag the same customers "1", "8", and "15" using the route numbers of the trucks making the deliveries. You might use "Monday" to indicate that the customer is closed on Mondays...
In your application you are assigning known, predefined attributes to the properties. This is a standard 1:M attribute model. Displaying them using the tag metaphor does not make them equivalent to free-form user tags.
What is the best Practice to tag the properties:
1- To store these tags in a varchar column in PROPERTIES table using Shuttle box.If you do this, how do you:
<li>Efficiently search for furnished duplex properties?
<li>Globally change "fitted" to "built-in"?
<li>Report the number of properties, broken down by full floor, duplex, fitted...
OR
2- To store them in a third table Eg, PROPERTIES_TAGS (ID PK, PROPERTY_ID FK , TAG_ID FK ), Then use LISTAGG function to show the tags in one line in the Properties Report.As Why to use Look up Table, this the correct way to do this. It enables the data to be indexed for efficient retrieval, and questions like those above should be handled simply using joins and grouping.
You might want to investigate the possibility of eliminating the ID PK and using an index organised table for this.
OR
Do you have a better option ??I'd also look carefully at your data model. Ensure you're not flirting with the EAV anti-pattern. Should some/all of these values not simply be attributes on the property?