[FX.php List][OFF] posting an email address

[Derrick Fogle]

On Apr 16, 2008, at 3:53 PM, Roger Price wrote:
> Filemaker of course does use a primary key (recid) but this is not  
> user defined or controlled. It is this key that FX.php uses to  
> uniquely identify a record that is to be edited or deleted. However  
> that is not quite the same thing.

WARNING: Long, rambling email ahead. Read at your own risk.

I totally agree that FM falls some distance short of a "Real" RDBMS,  
for your reasons and many others as well. The v7-v9 architecture is a  
step forward, at least. But FMI's philosophy of what FMP should be  
still yields a "Fischer-Price" kind of product. The most disappointing  
facet, for me, is FMP's abysmal performance as a back-end DB. I'm  
still not thrilled with the WAN performance of native clients, either.  
The persistent (going on 10 years now?), unanswered cries from  
developers for event triggers gets irritating, too.

So why do I still use it? I started doing databases when I had a  
Fischer-Price level of understanding. As my projects got more complex,  
I got really damn good at the "Yet another calculation field", "Yet  
another relationship", and "Yet another layout" concept that still  
applies to FMP today.  I understand the very UI-based data management  
concept of what FMP is, and tend to like it. So, for me, it's mostly a  
level of comfort, familiarity, and relative skill level compared to  
other DBMS packages. I'm afraid I've become an "old dog." I seem to  
have trouble picking up new languages these days.

It still has lots of merit as a workgroup database system: reasonably  
easy to develop in and get basic functionality, it suits my personal  
graphics layout style and skills (yeah, I suck), and it's very agile  
in terms of being able to be modified as businesses and business rules  
change. There's obviously a place for the product even in today's  
world of technology.

Almost all my "other" experience is with MySQL and PHP. I've developed  
some really big, complicated applications with it. It just takes me a  
lot longer to get something up and running with these tools. But this  
is probably because I only did this heavily for about 4 years and was  
thrown into it without any training or guidance. I never developed or  
latched onto good frameworks for PHP. I still do almost all my  
development in a text editor instead of some reasonable tool like  
Dreamweaver.

There's a breaking point: I don't know where it is, but at some point  
FMP becomes a poor choice. If most (or maybe over half) of your data  
business is web-facing and you're just using FMP as a back-end, and  
not exploiting the client application, it's probably a bad choice. If  
you've got more than 20 or so users logged in and pounding away on  
data management at any given time, FMP may be a poor choice.

But... if you're just using FMP for keeping track of your recipes, I  
think you should be shot. I don't think anyone needs a database to  
cook. ;-) I see examples like this of how you could use a database,  
and I have to laugh because needing a computer and a database for  
these things is totally absurd.  Databases are business tools for data  
management.

There's certainly a niche for FMP. I think the application I'm  
supporting right now is a fair example: A workgroup of 6-10 people  
that do computer and AV installation and support. The DB is used for  
job tracking, time tracking, inventory, and billing. Out of the whole  
DB, I've only got 4 or 5 specific basically single-page web forms that  
tie into it. It works reasonably well and I'm certain it took me less  
time to develop it and support it than it would take me to do the same  
thing with PHP/MySQL. But if I ever have the chance to re-develop, I  
would probably ditch FMP, bite the bullet on development time, and  
gain the benefits that PHP/MySQL provide. In fact, the only thing I  
ever intend to develop in FMP in the future is a runtime application  
that has to work offline. But the real application is written in PHP/ 
MySQL, and the FMP database is just being used as an offline field  
data collection node.

Not sure if that answers your question, it's just my perspective on  
the whole FMP-VS-X issue.