Easy searching by hierarchical category...

rubyonrails-talk
1

I recently wanted to come up with a solution to searching by a category (E.g. Shoes), sub category (E.g. Shoes > Blue), or sub sub category to any depth. This represents an obvious DB challenge not to mention model objects in RoR. I've come up with an elegant solution using Binary Trees and thought it might be useful to others. I've documented it here:

http://web.me.com/adamfowleruk/adamslife/Blog/Entries/2009/1/13_A_Strategy_for_Hierarchical_Searches_in_a_single_SQL_entity_table.html

Note I've not used it in anger yet, and have not QA'ed the Ruby and Java code at the end of the entry, but the approach is simple enough and easy for anyone to pick up.

Category searching to any depth using 1 column/model variable. 8o)

I'd appreciate any feedback, especially if anyone can think of a more elegant way to do it?

If anyone knows of where best to place the re-implementation of the sqlite3 LIKE function in a RoR project I'd be grateful. I'll likely use it elsewhere too. (I may infact implement REGEXP rather than re- implement LIKE).

Regards,

Adam.

2

adamfowleruk wrote:

I recently wanted to come up with a solution to searching by a category (E.g. Shoes), sub category (E.g. Shoes > Blue), or sub sub category to any depth. This represents an obvious DB challenge not to mention model objects in RoR. I've come up with an elegant solution using Binary Trees and thought it might be useful to others. I've documented it here:

http://web.me.com/adamfowleruk/adamslife/Blog/Entries/2009/1/13_A_Strategy_for_Hierarchical_Searches_in_a_single_SQL_entity_table.html

Note I've not used it in anger yet, and have not QA'ed the Ruby and Java code at the end of the entry, but the approach is simple enough and easy for anyone to pick up.

Category searching to any depth using 1 column/model variable. 8o)

I'd appreciate any feedback, especially if anyone can think of a more elegant way to do it?

Adam, the usual way this is done is with the nested-set data structure, which effectively also uses btrees in the DB index for the "left" column. Searching by pattern match would be somewhat slower than such indexed nested-set searches.

Your method does have the advantage of being able to add children without having to fix-up the tree afterwards, and for giving each node a permanent hierarchy identifier that makes it easy to do subcategory searches in search-engine indices. The nested-set method can however be tweaked to have the same properties.