Back in the 1970s, a database system was released for the CP/M operating system called Vulcan. Ashton Tate bought the rights to it, and renamed it dBase. It went through a number of iterations and version numbers, and a number of companies produced "clones".
The architecture was interesting; it combines these features:
Using all of this, you can build quite powerful interactive applications to work with a set of database tables.
In the early days, the tools for building "forms" were somewhat primitive (they got more sophisticated over time). In those days, personal computers were not connected to networks, so programs were inherently single-user-oriented. When PCs started getting networked together, locking schemes were introduced to allow use by multiple concurrent users.
Much later, an ANSI committee, X319J, created a common "dialect" called xBase, trying to unify the functionality of notable commercial implementations such as dBase, Clipper, and FoxBase, with the result that it is typical to call these sorts of database systems "xBase systems".
Early implementations functioned as file-based systems, that is, programs accessed data through the OS filesystem, in which each table and index is represented as a file. This approach doesn't scale very well from the perspectives of either reliability (because any program on the system that accesses a table file has the ability to "muss it up") or scalability (because every program that accesses the database has to manage locks itself).
Some implementations have become available that have a central database manager process, as is common with SQL databases. Furthermore, SQL interpreters have sometimes been added to the set of tools, so "xBase systems" are sometimes really SQL systems.
Various xBase implementations are available for Linux:
At the "lowest level", there are quite a number of data storage systems that don't try to be terribly abstract, or to provide a complete "application environment". The characteristic example is the Unix DBM scheme, which provides a set of C function calls that allow you to store values -- associated with keys -- into a data file.
If your data storage needs are simple, it may not make sense to pull in the full sophistication of an SQL system. Furthermore, the "serious database" systems typically tend to require some administration effort, often including setting up server processes, user authentication, and the likes. If you have an application that merely needs to "store some data", a DBM-like system may be all you need.
Some SQL database systems are (or have been) based on these sorts of libraries. For instance, Informix implemented a C-based ISAM library that was often embedded in applications; the Informix SE SQL database system was implemented on top of that, as tables were represented as ISAM tables.
There are a couple of SQL databases that have been built atop DBM. One of the most interesting examples is that "transactions" were brought to MySQL when they attached it to Berkeley DB, a modern version of DBM that supports transactions and storage of multiple "tables" within a single data file.
The major families of these databases include:
These systems tend to be highly API-oriented; while an SQL database often provides a lot of generic tools for building queries, and you tend to describe your query, these sorts of databases almost always require writing programs to "walk" through the data.
Linux systems almost always include some set of NDBM, the "New" DBM implementation, SDBM, ODBM, and GDBM, the "GNU" implementation.
The typical API looks like:
DBM *dbm_open(char *, int, int); void dbm_close(DBM *); datum dbm_fetch(DBM *, datum); datum dbm_firstkey(DBM *); datum dbm_nextkey(DBM *); int dbm_delete(DBM *, datum); int dbm_store(DBM *, datum, datum, int);
The Perl language popularized the idea of tying DBM tables to Perl
associative arrays, with the result that in Perl, once you tie a name
to a DBM file, you can transparently use ordinary assignments like
$A["this"] = "that", rather than something
like dbm_store(A, "this", "that", 4).
The Python AnyDBM_File documentation page describes some of the similarities and differences between different DBM implementations.
These systems are often embedded inside applications.
Notice that many of the vendors of ISAM-like systems also sell SQL databases; once you've got the low level library to store and retrieve data, it is pretty natural to build further layers of abstraction on top of that, such as SQL interpreters. That brings us full circle back to SQL, where we started.
Another one
Another one for indexing constant data, similar to CDB, is PureDB (http://www.pureftpd.org/puredb/) .
It's used to index virtual users in Pure-FTPd (http://www.pureftpd.org/), but it's also distributed as an independent set of library (http://www.pureftpd.org/puredb/) .
The API is simple and the reading library is extremely small.
DynDB
I'm awfully sorry for the double post ("reload" did the trick).
An interesting alternative to ndbm/gdbm/sdbm is DynDB (http://www.ohse.de/uwe/dyndb.html) .
DynDB works very well for non-constant data, because it supports concurrent writes (something that *dbm libraries don't support) .
It merges the efficiency of cdb with the write abilities of *dbm.
Have a look, it's really a promizing project.
Another missing category
Pliant is implementing a completely different database engine.
The general idea is to store the database as a tree, which
is much more flexible that the 'tables' model, and is mapping
staight forward the URL notion. With Pliant database engine, a database is stored in a single file even if it's a complex database.
The second idea is that the database is handled in the main memory, and the disk file format is HTML like ASCII with each modification appent immediately at the end of the file so that killing the database server process won't hurt.
See Pliant project at
http://pliant.cx/ (http://pliant.cx/)
for extra details.
What about MetaKit?
MetaKit is an embeddable high-power database
engine, with lots of language bindings. You can see
it at http://www.equi4.com/metakit/
Clip
There is one more Clipper-compatible compiler:
http://www.english.itk.ru/clip/index.html
CDS/ISIS database
one more,
Isis is a simple, yet powerful database system with a large installed base since the 80s. Since it's well suited for bibliographic data, it's commonly used in libraries, and since it's very low cost, especially in those running on a low budget.
Introduction to the isis db
An isis DB is a list of rows of unspecified structure, each identified by a unique number, the rowid (a.k.a. mfn).
Each row is a list of fields, and each field has number (tag) and a string value. Within a row there may be zero, one or more fields with a given tag. While the field's value usually is a textual representation of data in one or the other character encoding (commonly one of the IBM/DOS code pages), it may actually contain arbitrary bytes. (Extract from http://www.openisis.org )
Big category of non-SQL databases missing
I mean MUMPS language/DBMS. For example: http://sanchez-gtm.sourceforge.net.
Object Databases
Ever heard of object databases?
These are able to model the world much better than
"classical" databases. We are now trying some
experiments on top of Quiper DB (Quiper DB is a
relational/hierarchical data store; see quiper
project in FM or quiper.zapwerk.com) for binding
it to Java and store Java objects directly in DB
(including references between objects). Side
effect is that no structure infos are necessary
and one can later change Java classes to contain
more fields without ever thinking about
restructuring the database.
However, this poses some additional problems, like
garbage collection of unused objects and the like.
MVDB - Multi-Value Systems
You might also want to check out how multi-value systems work. See http://www.rainingdata.com/ for the Pick database system or http://www.jbase.com/ for another implementation that runs well under Linux.
See also http://hometown.aol.com/mbtpublish/index.html for terms definitions w.r.t. MVDBs and http://linas.org/linux/db.html for a better list of database systems for Linux.
These all include a Basic-like language that allows you to write quick and/or complex programs that directly access the data structures in the database system. Database files are all files within a somewhat hierarchial structure.
Re: Another missing category
Notice also that Pliant project may be found while browsing the category Database :: Database Engines/Servers.
Re: MVDB - Multi-Value Systems
Not only, but also, a developing Open Source implementation of a multivalue database system - MaVerick (http://freshmeat.net/projects/maverickdbms/).
Heard about tdbengine yet?
Another possible non-SQL rdbms for linux (and windows) can be found here :
http://www.tdbengine.org (http://www.tdbengine.org target=_blank)
It's a freeware/open source rdbms which is very compact, has a big feature list and of course is not queried by using sql. It has its own script language.
Perhaps you like it
hamsterdb
hamsterdb's first submission was in September 2006. It's a DBM-like library written in ANSI-C concentrating on high performance. It can run as in-memory database, use memory-mapped I/O, supports database cursors, variable length keys and records and can handle multiple databases per file.
http://freshmeat.net/projects/hamsterdb/