Success -- MySQL / MyODBC install

[michael d hoskins]

On temp tables....    A log can certainly be stored flat or in a table,
etc.  I've thought about this, but I think that writing an external log
that's basically a flat file that can be replayed in the event of a
crash is safer.

What you're saying is true, but if the temp table(s) need to be
recovered after a db crash, then you got the same issue, or possibly a
worse one.

On speed (in your next email, which just came in:)  "Given the lack of a
transaction log (and other things), the latter three operations are
generally faster."  That is the point.  MySQL cut features for speed.

Postgres, on the other hand, has the goal of total/nearly-total SQL
compliance, while striving to be cutting-edge as an Object Relational
Database System.  (It's considered to be ahead of the "big four," here.)

BTW, sometimes a well-designed log can speed things up, if it's a
cyclical log that keeps appending to itself until full.  This avoids
random I/O and makes all writes sequential.  An example of this is a new
Linux filesystem called LinLog:
http://www.complang.tuwien.ac.at/czezatke/lfs.html  If a database was
designed around this ideal, you could get an *increase* in speed from a
log, as well as an increase in reliability.

-----Original Message-----
From: watts [mailto:watts at jayhawks.net]
Sent: Friday, April 07, 2000 2:45 PM
To: kclug
Cc: watts
Subject: RE: kclug - Success -- MySQL / MyODBC install

On Fri, 7 Apr 2000, michael d hoskins wrote:

> The main solution I see here is to force yourself to do all work
> through a custom API which forces some kind of "transaction" system:
> have unique keys, some extra programming code, and a log or a buffer
> for your transactions that includes some kind of home brew
> checkpointing.

Yeah, you can accomplish a lot of this via temporary tables.  However,
it's a real pain.

> I don't believe in having extremely important productional data in
> MySQL, just as I don't believe in putting extremely important
> productional data on 4mm tapes.  I'd totally suggest MySQL to small
> and some medium ecommerce sites, provided steps above are taken.  I'd
> never suggest that Sprint long distance use it for productional data,
> although internal data would usually be OK, especially as a
> replacement to Access.

Yes, I completely agree.  It's very well suited to websites that serve
up
a lot of static data - like /. - I just get concerned when I see people
trying to do ecommerce on it though.

> Access has weird compliancy issues.

Welcome to the world of Microsoft.  :-)

> I can't remember if FMPro finally got SQL built in, or not.  Is FMPro
> finally truly relational, allowing for many-to-one, one-to many, and
> many-to-many relationships?

It's been too long since I played with it, I can't remember anymore.

Jeffrey.

o-----------------------------------o
| Jeffrey Watts                     |
| watts at jayhawks.net            o-------------------------------------o
| Systems Programmer            | "Over himself, over his own mind    |
| Sprint - Systems Management   |  and body, the individual is        |
o-------------------------------|  sovereign."                        |
|  -- John Stuart Mill, "On Liberty"  |
o-------------------------------------o