I asked my Nephew who is in grad school about which SQL servers might work
for a new version of Flex. I thought sometimes Universities hear about
things that are not so well known. For what its worth his comments are
below.
Uncle Jeff,
There are a number of options. "The best" option is Oracle - it comes with
commercial versions on Linux, Windows, Mac, Solaris, etc and is by far
considered the fastest, most feature filled database server available. But
it's generally extremely expensive.
If you're looking for free systems, MySQL is probably the best free system
that you could have access to. It is available for all the major systems,
it's used by lots of commercial and free applications, websites, etc, and
supports a large number of engines which can be plugged in - MyISAM which is
super fast, InnoDB which is a bit more stable for not corrupting data, and
others.
Postgres is also available for most of the systems and is MySQL's biggest
free competitor. It's possibly not quite as fast as MySQL if you're using
MyISAM, but when compared to InnoDB and the other MySQL storage engines that
are, in my opinion, "better" than MyISAM, Postgres is just as good.
There are other ones, not quite as big as the above two, like Firebird and
SQLite that I know of. I don't know much about them, but Neil and Andrew
were adapting Translator's Workplace to work with Firebird, so it might be a
decent option and is known to be very mature, being a fork from Borland's
commercial database server. SQLite is usually used for applications that
need the server to be embedded into the application directly.
In short, my recommendations, if you don't want to purchase Oracle, are
either MySQL or Postgres, and that really depends on what your
administrators and programmers want to use.
From: flex-list@googlegroups.com [mailto:flex-list@googlegroups.com] On
Behalf Of Steve Miller
Sent: Monday, May 18, 2009 10:17 PM
To: flex-list@googlegroups.com
Subject: [FLEx] Re: database engine choice
> Is the team planning to add support for other database engines, so
> that FLEx will work with other database engines as well as SQL Server?
> Or has a decision been made to replace one database engine with another?
We have not yet made a decision about what database engine(s) to support,
except that we know SqlServer will not be the only one because it is not
available on Linux and supporting Linux is one of the goals of the changes
we are planning. We hope to pick an engine that will replace SqlServer on
both platforms, be much easier to install, and give a similar level of data
security.
We also are interested that it perform well, and the Linux guys are
particularly interested in using an engine that uses little memory. (SQL
Server was really meant for servers, not laptops, and is a memory pig.)
Getting an open-source database is also a high priority. Fortunately
open-source databases have come a long, long ways in the past decade, and we
have a wide range to pick from.
To more closely answer David's original question, we could decide to use one
database engine for some types of hardware such as low-power devices,
another database engine for the more common Windows laptops, and another
engine for a web server (someday maybe). However, using three engines
instead of one means tripling the effort for programming, installation, and
maintenance. We can make better use of programming time if we could find one
that does everything we need. That may not be possible in the end, but we're
trying. I have put in a couple weeks of research on the topic, if anyone's
interested.
The "rewiring" we have in mind should allow us to plug in different
databases, and see how they work. It also means that someone really wants a
different engine than the one we chose, has sufficient ambition and ability,
and hopefully(!) good reason, he can swap out the engine for the one of his
preference.
More technically, one of the goals is to remove the object-relational
<http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch>
impedance mismatch.
I can provide more details to anyone interested.
Steve