Linux Database Classifications

There are two major ways of classifying the database systems available for Linux:

Commercial vs. Free Linux Databases

Commercial Linux Databases which are sold for a pricer.

Free Linux Databases that do not cost anything for a license.

Compatibility/Means of Functioning

xBASE

This is traditionally a "PC" oriented system, of which the first version was known as Vulcan, and ran under CP/M . It was later renamed dBase, and later versions and competitors have followed. Eventually it was purchased by Microsoft and rolled into their Foxbase offering.

You can obtain old dbase versions here.

The system model generally involves data structured in a dual fashion similar to ISAM databases (Indexed Sequential Access Method) with "data" files containing data, and "index" files containing index information.

Originally, the term "access method" referred to the way that data was physically stored on a magnetic tape or disk. It was very specific according to the particular kind of tape or disk drive. Over time, we've come to appreciate the usefulness of shielding the hardware details from the application program. A database program should not be concerned with what type or brand of device is used to store the files.

• More modern systems use "extent-based" allocation systems to better support the handling of tuples of varying sizes.

SQL - Structured Query Language

Ingres was the progenitor of the modern "query language," with its QUEL query language; a similar query language was then designed that we now know as SQL. SQL is arguably inferior to QUEL, as QUEL had a syntax that is simultaneously simpler and more powerful than that of SQL.

The system model typically involves there being a central database manager "engine" or "process;" application programs do not have direct access to the data. This allows data to be relatively protected from corruption/misuse by rogue processes.

It is common for the database manager to use a variety of the "nonrelational" database tools to implement tables; commonly used in older systems are ISAM access methods. The use of nonsequential hashed methods similar to DBM are commonly available with more modern database systems, although since the properties of approximate-match searches with hash tables are extremely poor, they are not as popular.

SQL is not without its problems: There are a number of other problems that injure the notion of calling it "relational".

• It doesn't provide a perfectly regular set of "syntax".

• It suffers from common bits of mathematical illiteracy such as lying about the nature of data types. The pointed example: REAL types are absolutely not like the domain of real numbers you find in mathematics. The REAL type in SQL is, instead, a rational number representation with variable precision.

• SQL tables are not necessarily relations.

• SQL does not support relational domains, although CREATE DOMAIN, supported in the more recent standard, is moving in the right direction...

• Typical implementations associate some sort of position to columns, which violates the definition of a relation.

• SQL permits duplicate records.

• SQL result sets can contain duplicates and nulls, notably when processing outer joins, thus violating closure.

  Everyone uses UNION ALL instead of UNION, because the latter is so much slower since it is required to eliminate duplicates.

• Views are not relations.

  No SQL system provides updatable views, and the lack of a sound theoretical basis for handling them is a problem.

The Third Manifesto responds to this by proposing a more strongly " relational" database language, supporting the notion of expressing more assertions and constraints about the nature of the data within the database engine. This also somewhat parallels the way Prolog allows expressing both "facts" and " rules" as to how the facts relate.

• SQL - Wikipedia

• SQL Tutorial