Re: How to search?

MinZero wrote:

> > Is there a reason you cannot expand your site to include multiple search features? Are you even
> > providing the option to the user to, for example, not show the results from the Customers table?
>
> Quick answer: Usability. My experience as a user makes me believe
> having specific search features are appropriate for reporting
> functions, but not everyday use of a system.

My experience as a developer has been that, if given something that is both specific and usable, then the user will more often than not, not care. For example, if the user is in the Customers section of your site and they perform a search, should they get results from the Products table? My suggestion would be no.

> > Are you sure? It seems that you would only be searching on text-based fields (description, name,
> > street, etc). I get the impression that it wouldn't be reasonable to allow the user to enter a
> > date, for example, or a simple boolean value.
>
> True. Date, flags and such attributes is not of interest. My guess is,
> since no one can get the date right, it would never show up anyway and
> I don't have to worry about it. Searchable fields consist of those that
> have clear text.
>
> > We had a similar problem to overcome with our application (not SQL, but that's irrelevant).
> > What we had to do was actually separate the information stored, so that we could effectively
> > search it. Essentially, you build your own index to the information, then you can index into
> > that.
>
>
> > We have something like (schema names changed to protect the innocent):
>
>
> > Product -> [ProductID, ProductAvailable, ManufacturerID]
> > ProductData -> [FieldID, FieldName, FieldType, FieldDescription]
> > ProductIndex -> [ProductID, FieldID, FieldValue].
>
>
> > The ProductIndex table only contains those fields that we want to index. Any others are
> > included in the ProductTable.
>
> And 'FieldValue' in ProductIndex table has a flat text of all valuable
> information in your product record? Interesting.

Actually, no. The FieldValue in the ProductIndex table contains the searchable value ONLY for that field.

> Let's see. Then every
> time a record is updated/created I would compile it's valuable fields
> into a flat string and push it into a new table. Hemm. Or, to make it
> scalable, I could have an independent process to perform that task into
> a completely different DB, and proper API of course to search within
> that box. Does it make any sense?

> > > it's company, and not the whole company.
> > I'll assume you meant "not every company".
> Correct
>
>
> > I get the impression that you may need to adjust your user requirements before an elegant and
> > workable solution can be provided.
>
> True. I guess I was looking for a magic shortcut.
>
> Thanks,
> Mike

--