What is better? fpsql or MySql

[Fairlight]

On Fri, Aug 20, 2004 at 05:49:05PM -0500, Tony Freehauf may or may not have
proven themselves an utter git by pronouncing:
> i don't know this stuff. I did by fpsql. I don't know how expensive MySQl is?

Free under the GPL, although they outline situations in which you need to
purchase a commercial license.  These conditions are far more lax since
they changed their model some time ago.  Even if you need the commercial
license, it's $495 if you use InnoDB tables (Pro license) or if you don't,
then it's $295.  The InnoDB tables are the ones that can span multiple
drives, etc.

> Which is better? MySQL or fpsql?

Is that a can of worms I hear opening?  :)  The following are my -opinons-:

Long story short:  MySQL is a better -database- engine.  (PgSQL is supposed
to be even better.)  fP is a better -application- development kit that
happens to have a sufficient data storage system built in.  With MySQL, it's
the database engine, it has an API which you can access from damned near
any modern language (C, Python, Perl, PHP, etc.), but you bring your own
user interface code, print code, etc., etc., etc., in whatever language you
choose to use.

Think of it this way...  fP is a rapid application development toolkit.  It
lets you quickly develop pretty robust applications, but its data storage
engine is a bit of an antique.  MySQL is a decent enough engine (and
getting better as they go--4.1 is almost ready, and the 5.0 release will
introduce stored procedures and views), but you don't get the RAD part of
it at all--it's -just- the engine.  It's like buying a drivetrain but
needing to assemble the rest of the vehicle.

In that way, they're kind of apples and oranges.

If you need to bang out an application quickly and it relies heavily on the
user interface on a -terminal-, fP is the way to go.  If you're doing web
work, you can still use fP with any number of solutions like OneGate.  But
if you entirely don't need the fast report format development, and don't
use screens at all on the terminal, etc., you may indeed be better off
doing it directly in another language with another RDBMS that's also
network-aware.

If you use a mix of types of features, you're still better off with fP, as
you get the RAD aspects, and it's still capable of interfacing to the web
and other things utilising some add-on solutions.

Keeping in mind that you're used to fP, having been around it so long, I'd
say you're better off not moving unless you have specific storage needs
that fP can't meet.

For experienced fP developers, there's no doubt that you're better off
sticking with what you're used to unless you have a compelling reason to
switch.  Personally, I code mysql+perl with either CGI or a Tk GUI far
faster than I can code in fP.  Most of this is just due to the fact that
I find myself having to shift my mental gears entirely to program in fP
at all, because my personal recent history includes far more programming
in other languages that are a lot different and I'm just geared up to
develop in them, where I have done only a few serious fP projects in the
last 8 years.  

But even doing a Tk or CGI interface, your user interface development
sucks up the majority of the time and effort, and you may very well end up
with only 20 lines out of 1000 actually dealing with the database itself.
Designing UI's from the ground up takes a -lot- of work, and that's where
fP shines (ditto on reports).  The only bad thing about the fP UI is that
you're limited to 80x25.  Fast and powerful as Tk and ncurses are, and even
if I knew the Tk front to back and wasn't still learning it, and wasn't
rusty in curses, I still couldn't do a UI for an application as fast as
I can design a screen and the attendant event processing in fP.  No way.
It's just the rest of the processing that kills my speed, but that's -just
me-, and it's due to where I've focused for so long.  Given enough time
working in it, I could readjust to be just as proficient in fP as I am in
perl or whatever.

> Will fpsql sale make our product the best value in town?

If you rely soley on queries through it, and it's useful to you, maybe.
I thought it was read-only though, and couldn't do posting.  Is that an
incorrect impression I've gotten somewhere along the line?

>From what I gather, fpsql hasn't actually been seriously updated in half a
decade, maybe more.  It's useful, but the only thing really "new" about it
is the fact that they're now heavily marketing it after letting it languish
in their archives for years.

But your question's phrasing begs another in response:  WHY did you buy
fpsql, besides just to buy it to have it, or for completeness, etc.?
Nothing personal in this at all, but the very question you ask suggests
that you don't fully realise what it can do (or won't do) for you, and
bought it only having a partial idea of what it does.  And without knowing
for what purpose you bought it, I'm not sure -anyone- will be able to
answer your question directly or objectively, for lack of information with
which to evaluate it and reach a conclusion.

> your opinions will be appreciated.

Oh, I doubt -mine- will by some, but I'm used to it by now.  :)  Still,
this is pretty much as objective a viewpoint as I can put forward, and I
think it's pretty unbiased, and even pretty pro-fP.  (Surprise!)

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html