Search in multiple fields - Method?

[panchristo]

I am thinking of using an auto-enter Text field which creates a multiline key, using the words from each of the fields in the same table and using this as a way to implement a multi-field keyword search for the table through a relationship. (Let's call this KEY)

For example, in a related table I would have a KeywordSearch Global Field where I would enter a phrase and in a portal I would display records from the related table using the relationship KeywordSearch

Is this a correct methodology or not?

[Søren Dyhr]

It was perhaps years ago when indirection demanded presense of each field on the search layout, or in the special case where full individual indexes for each field is a luxury.

This was the topic Chris Moyer lectured upon some 5 years ago at Devcon, where the magic was done via something like:

http://www.briandunning.com/cf/394

I think it was refered to as cartesian search?

But I would however instead stack requests via a looping utilizing this:

http://fmhelp.filemaker.com/fmphelp_10/en/html/scripts_ref1.36.40.html

...or alternatively use that you can build a series of requests inside a perform find, and if you use the asterix will the search you modify be a modification on a seemingly "show all" ... here comes the word processor like find/replace handy because it deals diagonally in the series of requests.

I attach a small template showing this, make a small scroll thru the records to establish which searches makes some sense... the global search is done via the script!

Perhaps you would need to read up upon request as such:

http://sixfriedrice.com/wp/the-secret-life-of-find-mode-requests/

Enjoy!

--sd

globalSearch.zip

[comment]

See also:

http://www.fmforums.com/forum/showtopic.php?tid/201295/

[bruceR]

It is going to massively bulk up the file if that matters to you. There is something of a trend towards using fewer relationships and more native searches and list views, which can be QUITE fast.

[panchristo]

Thanks very much for the replies.

What I was thinking of though is rather different.

I need sth like a search-as-you-type kind of module, but for multiple fields at once and the results briefly shown in a portal. That's why I came with the mthod described in the beginning.

Any suggestions?

[panchristo]

It is going to massively bulk up the file if that matters to you. There is something of a trend towards using fewer relationships and more native searches and list views, which can be QUITE fast.

Is there any way I could combine what I need with what you suggest to a more intuitive GUI?

[bcooney]

Perhaps an upgrade to FM11 for the QuickFind feature?

Honestly, I never understood the need for finds across multiple fields.

[Fitch]

Searching across multiple fields is more Google-like, the attraction being that users are already familiar with it.

I'd recommend these links:

If you want to use a portal, you're pretty much stuck with some kind of multi-value key.

http://sixfriedrice.com/wp/script-triggers-filter-as-you-type/

My preference is to use a list instead if possible.

http://smallco.net/index.php/services

(Click on "Feb. '09 - Ergonomic Stimulus Award Winners" -- I talk about type-ahead searching about 10 minutes in.)

This is a great solution but doesn't do the portal type-ahead.

http://www.seedcode.com/cp-app/ste_cat/fmsearchresults

[bcooney]

"Searching across multiple fields is more Google-like, the attraction being that users are already familiar with it."

Understood. But, so is the "Back" button.

[bruceR]

"Searching across multiple fields is more Google-like, the attraction being that users are already familiar with it."

Understood. But, so is the "Back" button.

But you have no point.

You're comparing apples and bulldozers.

The need for comprehensive search is real and valuable and has no effect on data integrity or workflow sequence.

The fact that a "back" button doesn't always make sense in a database is a very different matter.

[bcooney]

OK, Bruce, I suppose I could have expressed my thoughts with more detail in order to make my point, and yes, comparing Spotlight to the Back button is reaching.

The thought and consideration that I was attempting to communicate is that techniques/interface design decisions need to be made in the context of both the requirements and the tool that you are using.

Panchristo posts have often been questions of how to achieve complex interface techniques. Sure, these tricks can be accomplished, but I shudder to think of supporting these solutions.

So, perhaps I should have just asked for more specifics. Why does he need the Google-like search in this specific case? I wouldn't be surprised if the answer turns up a less than optimal data structure.

[Søren Dyhr]

ut you have no point.

You're comparing apples and bulldozers.

The need for comprehensive search is real and valuable and has no effect on data integrity or workflow sequence.

The fact that a "back" button doesn't always make sense in a database is a very different matter.

Well as I read it, was Barbara raising the "out of realm" yellow flag ... similar if a kind of info could be hidden away nearly every field, isn't it really database intended stuff we're dealing with, but lots of fields containing more than one fact per field, and by it a bad normalization!

It isn't more far fetched than your speak of trend, a trend which I btw have noticed as well.

--sd

[panchristo]

Thank you all for your valuable considerations.

Since I entered FMForums I have to admit I am constantly trying to balance my thinking between correct data structure (aka normalization, integrity, etc) and elaborated GUI. I have to admit I have learned a lot and want to continue that way. Sometimes though, it has appeared to me that an intuitive and more "natural" way of application thinking incorporated in a DB application might as well help to its long-term survival user-wise.

For example (related to the topic) I am trying to make an archaeological application, where info about objects will be stored. The originating excavation from which an object might have come from, comprises info such as address(up to 2 streets and no's), GPS points, Related person (owner of the site), City Plan Coordinates, Excavation abbrv. name, etc.

So, when entering a new object, it would be really handy if the user could easily spot the source of the objects (i.e. see above excavation info) and select it as the current source. Currently I also find it hard to improvise on a way to uniquely identify each excavation, since no address is totally unique etc.

However your thinking has many times guided me to much simpler (and stable) solutions and this is the reason I keep harassing you with questions all the time. :

So, to sum it up, if we suppose that I want to have a selection popup window (in list view) with all current sources for the user to select, how can I make a method of having something similar to spotlight(is this correct?) for quickfiltering the results but by searching all of the fields of the table and not having to use a switching value list in front?

[Fitch]

The fmSearchResults link I posted above is what you want.

[panchristo]

Awesome tool!

It is however far beyond my current needs and budget...

By the way, your talk has done much to the right direction. if only I could find a performance-light way to incorporate the filtering fields in the header section into one!

[bruceR]

Well as I read it, was Barbara raising the "out of realm" yellow flag ... similar if a kind of info could be hidden away nearly every field, isn't it really database intended stuff we're dealing with, but lots of fields containing more than one fact per field, and by it a bad normalization!

It isn't more far fetched than your speak of trend, a trend which I btw have noticed as well.

--sd

She later clarified that point; but it certainly wasn't obvious in the beginning. In the beginning she was directly saying that there was something wrong with wanting "Google style" generalized search.

[comment]

Do you know the difference between "I don't see your point" and "You have no point"?

[David Jondreau]

:worship: :worship:

[Vaughan]

I am trying to make an archaeological application, where info about objects will be stored.

If I was designing a database for archaeologists I'd probably reverse my thinking and build the interface so the users HAD to dig around for information. :

[bcooney]

And Vaughan wins for "best post this thread."

[LaRetta]

And Vaughan wins for "best post this thread."

I agree, it rocked! Michael wins for making the best point to Bruce (who was coming down on you a bit brash, Barbara) I wanted to step in but Michael handled it much better (as always).

In fact, I'm going to refer to a round-about answer as an archaeological answer; a method of obfuscating code ... it truly tickled me.

Edited July 14, 2010 by Guest

[bruceR]

Do you know the difference between "I don't see your point" and "You have no point"?

Of course.

And you?

[LaRetta]

This is actually very funny ... it's like the response "same to you but more of it." Oh, some come-back that is! ROFLMAO!

[comment]

Let me put it this way: I don't see your manners.

[Vaughan]

Perhaps this thread should be buried now.

[panchristo]

If I was designing a database for archaeologists I'd probably reverse my thinking and build the interface so the users HAD to dig around for information.

:yourock:

[bcooney]

Yes, let the dust settle.