On Mon, Dec 24, 2001 at 08:18:41AM -0500, Russ Wright wrote:
<snip>
>
> 1. Database. - currently the app uses an MS Access mdb file. I don't know of
> any equivalent product under linux. Does anyone? I looked at PostgreSQL and
> MySql but they are too big for this app.
>
Although you probably won't go this way, I'll point out some lightweight
database products. All are free (beer).
1. db. This is the Sleepycat product, very mature, widely used, stable
and currently under development. It doesn't care what you put in your
records, so when you get the data out of the database, you have to
interpret it yourself; to db, a record is just a featureless chunk of
data.
2. xBase. This is a fairly mature product on SourceForge that emulates
dBase/Clipper/FoxPro functionality, without having to use those
programs. This is a C library, so you have to build C code around it.
3. Typhoon. Stable, but no longer in active development. Data files with
your choice of C datatypes, and separate index files. The functions that
come with Typhoon are similar in flavor to what you'd get in an xBase
product. That is, it is _not_ SQL. I don't know how good Typhoon is with
multi-user scenarios.
4. NoSQL. This is a sort of clone of the /rdb product. RDB is written in
Perl. The guy who wrote NoSQL rewrote a lot of the /rdb programs in sed
and awk to make them more lightweight. He also slightly changed the
structure of /rdb files. This is an actively developed product that uses
pipes and I/O redirection to manipulate data. The data is in flat text
files with tab-delimited variable-length records and a header. Index
files are available as needed. Of course, as the name implies, this is
_not_ a SQL product.
5. SQLite. This _is_ a SQL product that stores all data from various
tables in one file, with any indexing information. It has C hooks, and
is similar to interfacing with PostgreSQL and MySQL in programs. It is
not, to my knowledge, client-server, so I don't know how well it does
with multi-user. Also has command line utility similar to PostgreSQL's
psql.
As regards getting the data out of mdb and into something else, you
should be able to export it as comma- or tab-delimited, and then suck it
up using something else. PostgreSQL will eat this data with little
massaging, I believe.
Paul
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:22:15 EDT