The Character of db++ and typical Applications

Curriculum Vitae of db++

The Character of db++ and typical Applications


Using the db++ modules dbcreate and dbappend, relations can be specified and filled with imported data in double quick time without the need for exhausting definition aria. The swift application of dbmodify during or after this process will structure the relations for efficient indexed access over diverse types of primary and secondary indices.

Here a titbit, each relation is a single file containing both data, indices and structural information - usually in Btree form - with powerful algorithms developed by Concept asa for an extremely efficient and automatic rollback using the bitmap controlled shadow storage concept. For the application programmer this means that many standard Unix commands can be applied to db++ relation files and combined with specialised db++ commands, for example in pipe lines.

The integration of db++ utilities in the Unix environment should not be underestimated: it saves considerable administration effort and dramatically reduces the learning curve involved with gaining familiarity with a large number of specialised propriety database tools.

This characteristic that "db++ runs not under but with Unix/Linux" is means that customising of application programs - e.g. turn-key solutions for wholesale/retail and material requirements planning - to realise specialised client requirements can be undertaken by personell with limited knowledge of db++.

It is nice for the professional developer to know that his application will just run and run - like the one time famed Volkswagen Beatle - without needing to employ specially trained database administrators at the client site. But for the programmer of custom software, the effiency of the development cycle is paramount.

And just in this area, those developers who have fallen in love - and who can blaim them - with the the ubiquitous "mega tools" perl from Larry Wall and Tcl/Tk from Professor John K. Ousterhout will be delighted.

db++ has direct interfaces to perl, Tcl/Tk and Java as well as the traditional "C" programming interface. The cdbServer is now also programmable in Tcl at run-time. This means that functionality which would previously have been programmed on the client side can now run within the cdbServer (actually we should speak of the cdbServers since one or more cdbServers can be running on any host in the network). This can cut network traffic by an order of magnitude and thus considerably improve the already very high performance of db++ transactions.

Both the perl and Tcl/Tk interfaces permit the programmer to model and develop highly specialised database access methods in an extremely simple and efficient fashion. Especially the possibility of externalising client specific functionality in perl or Tcl scripts frees C and/or C++ code from client specific code. Maintaining and modifying such tailor made code - even for the most esoteric of client desires - is reduced to a minimum.

Even if you do not share our opinion that Tcl is the only serious contender for the accolade "the (non-proprietary) 4GL language for the 90's and beyond" and are not impressed by the huge world-wide community of users (and testers) which are in constant dialogue with each other and John K. Ousterhout via the Internet, db++ also provides interfaces to ODBC and to Java.

At present the Java interface has been mainly installed for browser based retrieval front ends to implement an efficient connection from an applet to a remote db++ search engine.

Aficionados of db++ have often been heard to ask:

Is db++ flexible and simple - or just simply flexible?

Ask Concept asa about typical applications built with the db++ database system - the answer is in the first line commercial applications. Thus there are, for instance, ca. 800 installations of wholesale turn-key systems and considerably more than 10.000 installations of a payroll package developed with db++.

In total there are somewhat more than 15.000 installations (sites), running on Unixware of Novell, Sun Solaris, HP-UX, IBM AIX, Sinix, Linux and Windows platforms. Whereby the last two platforms are now dominant.

Scalability: Typically a site will support between 2 and 100 work-stations (terminals and/or PC's) accessing one or two server machines but installations with up to 300 work stations, sometimes up to 500 simultaneous client processes accessing up to 5 GB of user data can be handled easily with a single dual processor Pentium4 machine with 1024 MB RAM on both LINUX/UNIX and MS-Windows platforms. By request from EADS Airbus the upper 2 GB limit to the size of a single relation/table has been removed for the Sun Solaris version.

Since db++ still fits on to a single diskette, we expect that in the near future a new application area will arise in the embedded Linux market where db++ would require no more than 2-4 MB Flash and 4-8 MB DRAM.

In addition to commercial applications, db++ has a smaller but significant installed base in the public sector: For instance, at 120 different sites in North Rhine Westphalia; A number of technical applications in the area of network control, administration and statistic especially by the German Telekom and in the banking sector; Several interesting applications in the area of process and quality control; Several installations in the area of technical documentation.

Curriculum Vitae of db++

2000 This version of db++ is a major extension implementing the concept of local caching. Also implemented in this version is a facility to enter and retrieve a number of user (specific) typed keys, i.e. float, integer, date, for each relation. The usage of these keys is independent of all the standard database operations, i.e. version control or in shell/perl scripts. The 2 Gigabyte maximum size of each relation has been removed in the Sun-Solaris distribution.
1999 The ODBC daemon process dbquery has been generalised so that low-level SQL and AQL queries are possible which by-pass the (sometimes) extremely inefficient ODBC protocol.
1999 Alpha/Beta :-) implementation of local caching.
1998 New data types binary, blob, long-text, sequence and time-stamp are now available.
1998 Optimisation of queries has been improved so that the space required on disc in sorting large relations is often dramatically reduced. This can lead to an order of magnitude in improved performance.
1997 Further development of the monitoring/tuning tool giving information i.e. on page read/writes, locks, non optimisable queries, time per transaction, counts of closes/opens by least frequently used algorithm etc. The output of this information is tagged by the name of the client program, and client host and can be triggered by high water marks or requested on demand as a history list of the recent activity of the cdbServer.
1997 Flexible, transparent mapping of relations/tables names to machine/server/directory combinations. This makes it possible to specify constant virtual names for relations in designing applications. Mapping the virtual names to real relation files on the intra/internet can be postponed to the time of installation of the software.
1997 Establishment of C++ compatibility with the "C" interface of db++. (Note: this means that db++ "C" routines can be called from C++Code, a C++ class interface in the sense of the perl, Tcl und Java interfaces is not yet available)
1996 ODBC interface based on the Sun RPC and MS-WinSock specification compliant to ODBC 2.0; Development of the Java interface with Symantec Cafe; First internal (CITAT/X) and external Java projects; Port to Windows95/NT; The Client/Server model now supports networks with heterogenous platforms (Clients: Unix, MS-DOS, Windows3.11, Windows95/NT; Server: Unix, WindowsNT)
1996 Improvement of the Tcl 7 and the perl5 interfaces to permit dynamic linking/loading of the standard Tcl libraries from db++Servers as well as the dynamic linking/loading of db++ libraries from standard Tcl or perl.
1994 Programmability of the cdbserver in Tcl; Several cdbServers run on one or more host machines. Introduction of the "freeze" concept - extension of the bitvector controlled shadow storage concept to coordinate potentially complex, long running queries with shorter, updating transactions; Port to Linux.
1993 dbtcl, Development of the interface to the Prof Ousterhout's scripting language Tcl. Additional "unique" option for compact secondary indices. Logging option for roll-forward restoration of relation files.
1992 Storage and query optimisation.
1991 Based on the theoretical investigations of the previous year, development of the RPC version for client/server IPC - this enables transparent connection of work stations and servers of different endian machines; Update for all important Unix platforms - IBM AIX, HP-UX, SNI Sinix, Sun Solaris, UnixWare, SCO V.4, Linux, Data General, Motorola PowerPC and 88k, Silicon Graphics
1990 Detailed investigation of various IPC schemes to give db++ cdbserver network capability (RPC, sockets, semaphores,shared memory).
1989 dbperl, development of the db++ perl interface - the genial script language of Larry Wall - first designed as a more powerful alternative to db++'s native report writer "dbrpg" but now often preferred as a flexible alternative to the "C" interface library for creating complex, customisable client/server applications.
1988 Compact secondary indices; additional, diverse locking facilties at the granularity of the tuple. Porting to a large range of manufacturers and Unix versions including IBM AIX, NCR Tower, Olivetti V.4, Interactive, Generics, SCO Xenix und Unix.
1987 Development of the db++ based retrieval system CITAT/X, which combines fast inversion and search methods with the RDBMS technology.
1986 dbfsck, Programme for the verification of relation files and their restoration if found to be defect; Ports to HP-UX und Sun OS
1985 First client/server implementation based on named pipes; Ports to Siemens PCX and PCS Cadmus
1984 Non-compact but extremely fast implementation of secondary indices, additional data type Deutsch for correct collation of umlauts; Ports auf DEC Vax and Kontron


Concept asa GmbH
Obere Pforte 1
D-35428 Langgöns
Tel: ++49 (0)700 777977-71, Fax: -99