[FX.php List] FM Scripts vs. PHP
Gjermund Gusland Thorsen
ggt667 at gmail.com
Fri Oct 26 08:25:28 MDT 2007
>From what I understand, the combination of layouts and relationships
make up the equivilent of an OLAP cube...
ggt667
On 10/26/07, Leo R. Lundgren <leo at finalresort.org> wrote:
>
> 26 okt 2007 kl. 03.45 skrev Dale Bengston:
>
> > Joel,
> >
> > I stopped using related fields on layouts back with v6. My
> > anecdotal experience tells me it's faster to go get the data from
> > the child records from a separate, optimized layout than to pull it
> > through the parent record.
> >
> > Other databases don't have such things as portals, so it's all done
> > with separate queries. MySQL is heaps faster than FMSA for
> > everything we've thrown at it.
>
> Am I misunderstanding the features of portals? In other databases you
> have the ability to JOIN tables, which seems much more flexible to me
> in that with FM portals you can only go one level down a hierarchy,
> so to speak. That's a pain in the ass, and it's made me collect my
> data in other ways than using portals.
>
> -|
>
> > Dale
> >
> > On Oct 25, 2007, at 12:24 PM, Joel Shapiro wrote:
> >
> >> Thanks d,d,&ggt
> >>
> >> Dale: Out of curiosity -- & because I don't know MySQL yet -- if
> >> you don't use related fields are you hitting the database
> >> additional times (e.g. once for parent, once for related
> >> children)? I'd thought the conventional wisdom here was that it's
> >> faster to get everything in one hit off one layout -- at least w/
> >> FMP.
> >>
> >> -Joel
> >>
> >>
> >> On Oct 25, 2007, at 12:27 AM, Gjermund Gusland Thorsen wrote:
> >>
> >>> The answer lays in maintenance, if the php task and the ScriptMaker
> >>> task can bring maintenance issues, make both in FileMaker if
> >>> possible.
> >>>
> >>> If not make one script for each medium.
> >>>
> >>> ggt667
> >>>
> >>> On 10/25/07, Dale Bengston <dbengston at preservationstudio.com> wrote:
> >>>> Derrick is dead on: it depends. There are certainly cases with our
> >>>> existing clients where we are tapping into a process that invoke
> >>>> complex scripts that are part of a client-server installation. In
> >>>> such cases, it doesn't make sense to replicate the process in PHP.
> >>>>
> >>>> On the other hand, we are doing all new development so that it
> >>>> can be
> >>>> switched between FMP and MySQL. This means no related fields on
> >>>> layouts and no native FMP scripts. It's amazing how much faster
> >>>> data
> >>>> retrieval is without any related fields on a layout.
> >>>>
> >>>> So for us, it's a matter of how tied to FMP we want to be. Since we
> >>>> choose to support more than one data source, we do as much as
> >>>> possible in PHP. But in certain cases for existing FMP clients,
> >>>> it's
> >>>> easier (and cheaper) to tap into the existing scripting.
> >>>>
> >>>> Dale
> >>>>
> >>>> PS I concur with everyone who's commented about the pre v7 use
> >>>> of FMP
> >>>> scripting from the web: it is ugly. On the other hand, I used to
> >>>> do a
> >>>> lot of stuff with AppleScript and v6 from the web. Ah, those
> >>>> were the
> >>>> days.
> >>>>
> >>>>
> >>>> On Oct 24, 2007, at 9:04 PM, Derrick Fogle wrote:
> >>>>
> >>>>> On Oct 24, 2007, at 7:34 PM, Joel Shapiro wrote:
> >>>>>> Anybody else care to pipe in?
> >>>>>
> >>>>> As always, it depends what you're doing. If your operations are
> >>>>> mostly native FM with only a small web-based presence, sticking
> >>>>> with FM is probably the best choice. But I can't recommend
> >>>>> using FM
> >>>>> scripting, or even FM at all, if you're good with PHP and your
> >>>>> operations are primarily web-based.
> >>>>>
> >>>>> FWIW, I use FM8SA one one machine, and Apache/PHP on a nearly
> >>>>> identical 2nd machine (both XServes). Processing data in PHP is so
> >>>>> much faster than processing data in FM, it's not even funny. I'm
> >>>>> competent enough with both FM and PHP, and I invariably fetch the
> >>>>> minimum raw data required out of FM with as few actual
> >>>>> interactions
> >>>>> with FM as possible, and do any processing needed for output to a
> >>>>> browser with PHP.
> >>>>>
> >>>>> I can see where, if you want to update a whole bunch of FM records
> >>>>> with a single web submit, you will find a point where
> >>>>> processing in
> >>>>> FM will be faster than processing in PHP, simply because of the
> >>>>> time overhead of getting data in and out of FM. But I would
> >>>>> question any web application that modified a whole bunch of
> >>>>> records
> >>>>> with a single web submit.
> >>>>>
> >>>>> Derrick Fogle
> >>>>> derrick at fogles.net
> >>>>> _______________________________________________
> >>>>> FX.php_List mailing list
> >>>>> FX.php_List at mail.iviking.org
> >>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
> >>>>
> >>>> _______________________________________________
> >>>> FX.php_List mailing list
> >>>> FX.php_List at mail.iviking.org
> >>>> http://www.iviking.org/mailman/listinfo/fx.php_list
> >>>>
> >>> _______________________________________________
> >>> FX.php_List mailing list
> >>> FX.php_List at mail.iviking.org
> >>> http://www.iviking.org/mailman/listinfo/fx.php_list
> >>
> >> _______________________________________________
> >> FX.php_List mailing list
> >> FX.php_List at mail.iviking.org
> >> http://www.iviking.org/mailman/listinfo/fx.php_list
> >
> > _______________________________________________
> > FX.php_List mailing list
> > FX.php_List at mail.iviking.org
> > http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
>
More information about the FX.php_List
mailing list