[FX.php List] Google-type search across tables?

Steve Winter steve at bluecrocodile.co.nz
Wed Mar 28 00:47:21 MDT 2012


Hey Joel

How often does much of the data change…? if it's pretty often, (x times an hour) then you're probably going to need to stick with using FM as your data source… if it's x times a day you could consider pushing each of the fields you wish to search against, from their respective tables, into a single MySQL table, which has a single record for each block of data, which includes a 'source' field, so that you know which table it came from, and therefore which category it's in…

If it's only x times a week (or month or never) then you could also look at using a 'search' tool like solr which will definitely give you the ability to do google style searches, up-to and including the ability to do type-ahead type searches across the whole lot… somewhere I've got a python indexer, which pushes specified fields from FMP into a defined solr schema (along with all the instructions to get solr running as a 'plugin' to FMS (on Apache)) if you're interested…

HTH
Steve

> Thanks again, Webko.  Good to hear from someone who's tried it!
> 
> Anybody else?
> 
> Cheers,
> -Joel
> 
> FWIW: Re: editing or creating multiple records at once, I've found it can be a *lot* faster to edit multiple records if they can be turned into related records in a portal of one "parent" record, and then just edit the one parent record.  
> For creating multiple records, the fastest way by far was via an FM script:
> http://blog.jsfmp.com/post/19243201571/  (the last 2 examples)
> 
> 
> On Mar 27, 2012, at 4:47 PM, Tim 'Webko' Booth wrote:
> 
>> Dear Joel,
>>> 
>>> I've thought of concatenated fields, but the client wants to search on some "description" fields containing lots of text, and I'm concerned that that might really slow things down.
>> 
>> It would have to be fairly massive slabs of text to slow it down appreciably in my experience. Especially if you tune the layout to only have the search field on it.
>>> 
>>> I was thinking of multiple searches because they'd like the results to be filterable by category.
>> 
>> That's where overhead issues start coming into play - as everything is returned in the rather wordy FileMaker XML format and each search is run one after the other, lots of little searches become inefficient. I notice this particularly on one system where I can have over 50 new record or edit record requests.
>>> 
>>> By "extend that for related tables", do you mean have one concatenated field in the parent table including child fields/records?  Or something else?
>> 
>> The first. As I said, then the issue becomes identifying where the actual match came from...
>> 
>> Cheers
>> 
>> Webko
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list

Steve Winter
+44 777 852 4776
steve at bluecrocodile.co.nz






More information about the FX.php_List mailing list