Re: Design Table & Search Question

tsearch indexes have to reside in the table where the data is, for the
automagical functions that come with it to work. You can define a
view that joins the tables, then search each of the index columns for
the values you are looking for.

In my experience, the LIKE searches are fast for relatively small
datasets, but they are often implemented funny, where a search for
'ING' (the company) would return zillions of records with verbs (and
gerunds) in them. tsearch is smarter than me. It knows where to stem
words and rarely gives unexpected results. Automotive nomenclature
will seldom be stemmed so you will get whole word searches which is
usually fine.

Good luck!

- Ian

On 30 May 2007 11:59:04 -0700, Gabriel Laet <gabriel(dot)laet(at)gmail(dot)com> wrote:
> Hi,
>
> I'm developing an application where basically I need to store cars.
> Every car has a Make and Model association. Right now, I have three
> tables: MAKE, MODEL (make_id) and CAR (model_id).
>
> 1) I'm not sure if I need or not to include "make_id" to the CAR
> table. To me, it's clear to associate just the Model. Am I right?
>
> 2) I'm thinking in the best way to search content. I'll need to search
> data across multiple-tables, and I'm not sure about the best way to do
> that. Should I use TSearch2 or just a bunch of LIKEs and JOINs
> statements?
>
> I appreciate any help :)
> Thanks!
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>