Charakter von und Applikationen mit db++

Curriculum Vitae von db++


Charakter von und Applikationen mit db++

Zum Anfang

Mit db++ lassen sich ohne große Definitionsarien mit dbcreate und dbappend ungewöhnlich schnell Relationen aufbauen und mit importierten Daten füllen, wobei als Zwischenschritt mit dbmodify noch rasch die gewünschten Schlüssel für die Relationen angelegt werden.

Eine Besonderheit ist dabei, daß jede Relation zusammen mit allen zugehörigen Schlüsseln jeweils in nur einem File abgelegt wird. Dies hat es einerseits der Concept asa ermöglicht ein sehr effizientes automatisches Rollbackverfahren mit Hilfe eines bitmapvektorgesteuerten Schattenspeicherkonzeptes zu implementieren, und ermöglicht es andererseits den Applikationsentwicklern, die mit der Datenbank arbeiten, Linux/Unix-Kommandos auf db++ Relationen anzuwenden und mit db++ Befehlen auf Shell-Ebene zu verbinden/pipen.

Letzteres ist nicht zu unterschätzen, es erspart erheblichen administrativen Programmieraufwand, der wie sonst üblich anstatt dessen mit datenbankspezifischen und damit proprietären Tools geleistet werden müßte.

Diese Eigenschaft, daß "db++ nicht unter sondern mit Linux/Unix läuft", ist mit ein Grund, daß das Customizing/Anpassen von Applikationsprogrammen auf kundenspezifische Wünsche in der Praxis z.B. bei Warenwirtschaft- und PPS-Systemen einfach und schon mit geringen db++ Kenntnissen vorgenommen werden kann.

Für einen professionellen Entwickler ist es zwar schön und unverzichtbar, daß seine Applikationen beim Endkunden ohne einen speziell ausgebildeten Datenbankadministrator zu bemühen angepaßt werden können und dann wie einst der "Käfer" einfach laufen und laufen, für ihn selbst aber steht zunächst mal die eigene Arbeitseffizienz im Vordergrund.

Hier werden vor allem die Entwickler begeistert sein, die die im Linux- und Unix-Umfeld häufig genutzten "Mega-Tools" Perl von Larry Wall und Tcl/Tk von Professor John K. Ousterhout schon kennen und schätzen gelernt haben.

db++ bietet sowohl für Perl als auch für Tcl direkte Schnittstellen neben der traditionellen C-Schnittstelle an. Inzwischen ist selbst der, oder besser gesagt die cdbServer von db++ (es können bei komplexen Netzwerken mehrere gleichzeitig eingerichtet werden), in Tcl programmierbar, wodurch mit dem dadurch möglichen Durchschleusen von ganzen Tabellen "on the fly" die an sich schon sehr hohe Verarbeitungsgeschwindigkeit von db++ nochmals gesteigert werden kann.

Perl und Tcl bieten dem Programmierer darüberhinaus die Möglichkeit eigene komplexere Datenbank-Zugriffstypen auf eine äußerst einfache und effiziente Art und Weise zu modellieren, d.h. eine genau auf seine Bedürfnisse zugeschnittene Entwicklungsebene für die Datenbank zu erzeugen. Dabei hilft vor allem auch die Auslagerbarkeit von benutzerspezifischen Funktionen in perl- oder Tcl-Scripts den Sourcecode der Applikationsprogramme von solchen Modifikationen frei zu halten. Damit wird verhindert, daß sich der Applikationsentwickler auch bei Individual-Lösungen trotz des intensiven Eingehens auf Benutzerwünsche bei Softwarepflege und Support das eigene Grab gräbt.

Selbst, wenn man nicht der Argumentation des übrigens "deutschen" Herstellers von db++ folgt, daß "Tcl die einzige nicht-proprietäere 4GL-Sprache der 90iger Jahre ist", weil sie wie Linux und Perl im Sourcecode frei zugänglich ist, und wie diese von John K. Ousterhout via Internet im Dialog mit weltweit einer Unzahl von Benutzern (=Testern) gepflegt und weiterentwickelt wird, wird man allein das Vorhandensein von vielen alternativen Schnittstellen - und hier bietet db++ inzwischen noch Java und ODBC an - als großen Vorteil dieser Datenbank begrüßen.

Derzeit wird die Java-Schnittstelle hauptsächlich in browserbasierenden Retrieval-Frontends für die Implementierung einer schnellen und effizienten Verbindung von Applet zur db++ Suchmaschine eingesetzt.

Fassen wir es aus der Sicht eines Programmierers zusammen, die Frage lautet:

Ist db++ flexibel und einfach - oder einfach flexibel?

Fragt man die Concept asa nach den Anwendern der db++ Datenbank, dann werden in erster Linie kommerzielle Anwendungen genannt, so gibt es z.B. ca. 800 Installationen eines Großhandels-Warenwirtschaftssystems auf db++ Basis und weit über 10.000 Installationen eines auf db++basierenden Lohn- und Gehaltssystems.

Insgesamt sind zur Zeit ca. 15.000 Installationen auf Novell/Unixware, Solaris, HP-UX, IBM AIX, Sinix, Linux und Windows im Einsatz. Wobei die beiden letzteren inzwischen klar dominieren.

Skalierbarkeit: Es sind Systeme mit bis zu 300 Arbeitsplätzen, heisst teilweise bis zu 500 Datenbank-Clienten unter Linux/Unix im Einsatz mit teilweise bis zu 5 GB Userdaten in den db++Relationen. Letzteres inzwischen auch bei einer MS-Windows-Installation. Und dies bei vergleichsweise geringen Hardwareanforderungen - meist reicht selbst bei grossen Installationen ein Pentium4-Doppelprozessorrechner mit 1024 MB RAM. Beginnend mit EADS Airbus auf Sun Solaris sind inzwischen mehrfach auch unter Linux und Windows Relationen/Tabellen mit mehr als 2 GB Speicher realisiert worden.

Aber: Da db++ immer noch (komprimiert) auf eine Diskette passt, rechnen wir nach wie vor damit, dass db++ zusammen mit einem embedded Linux auch in Emmbedded-Systems-Applikationen mit 2-4 MB Flash und 4-8 MB DRAM laufen kann.

Trotz der vielen kommerziellen und administrativen (z.B. ein Auskunftsystem in über 100 Verwaltungsstellen in NRW) Anwendungen von db++, heben die Entwickler von db++ immer wieder heraus, daß das RDBMS vor allem auch für technische Problemstellungen mehr als alle anderen Datenbanken geeignet ist, so gibt es inzwischen eine Vielzahl von Installationen im Network/Message-Administration/Statistikbereich, unter anderem bei der deutschen Telekom, und im Bankenbereich, aber auch interessante Installationen im Bereich der Prozeßsteuerung und Qualitätsicherung, sowie im Bereich der technischen Dokumentation.

Curriculum Vitae von db++

Zum Anfang
2000 Es wurden neu implementiert: (1) User Keys/Strings als user(firmen)spezifische "Stempel" für die Tabellen/Relationen, (2) Der Caching Algorithmus, (3) Tabellen/Relations > 2 GB für Solaris.
1999 Der ODBC Daemon Prozess "dbquery" wurde generalisiert, sodass auch low level SQL-Queries möglich sind, ohne dass oft langsame SQL-Interface nutzen zu müssen.
1999 Testversion des Caching Algorithmus.
1998 Die neuen Datentypen "binary", "longtext", "blob" und "sequence" wurden implementiert.
1998 Erweiterung der Optimierung des Queryprozessors mit dem Ziel temporäre Files entweder ganz zu vermeiden oder in ihrer Grösse zu reduzieren, die bei bestimmten Sortieroperationen anfallen, wenn die Keystruktur der Relationen vom User oder Programmierer besonders schlecht berücksichtigt ist.
1997 Weiterentwicklung der Monitoring-/Tuning-Tools mit Info über Page Read/Writes, Locks, nicht optimierte Queries, Zeit pro Transaktion, Anzahl der Closes/Opens durch den last recently used Algorithmus; die Informationen werden clientspezifisch entweder durch high water marks getriggert und/oder als History der Serveraktivitäten ausgegeben
1997 Flexibles, transparentes Mapping von Relationen/Tabellen-Namen auf Maschinen/Server-Kombinationen, damit können über virtuelle Dateibäume komplexe Applikationen besser strukturiert werden; dadurch kann (können) auch wesentlich einfacher als bisher der (die) Server Aufgaben für die Clienten übernehmen, z.B. auf Anforderung für diese neue oder temporäre Relationen auf einem Remote/Internet-Host erzeugen, modifizieren oder entfernen
1997 Herstellung von C++Kompatibilität (Anmerkung: macht das Einkompilieren von db++Modulen in C++Code möglich, keine eigene Schnittstelle im Sinne der perl, Tcl und Java Schnittstellen von db++)
1996 ODBC-Schnittstelle auf Basis von Sun RPC und der MS-WinSock-Spezifikation kompatibel mit ODBC 2.0; Entwicklung der Java-Schnittstelle mit Symantec Cafe; erste interne (CITAT/X) und externe Java-Projekte, Portierung auf Windows95/NT; das Client/Server Modell unterstützt nun Netze mit heterogenen Plattformen (Clienten: Unix, MS-DOS, Windows3.11, Windows95/NT; Server: Unix, WindowsNT)
1996 Überarbeitung der Tcl 7 und der perl5 Schnittstellen mit dem Ziel, sowohl das dynamische Laden/Linken der Standard Tcl-Libraries von db++Servern aus, als auch clientseitig das dynamisches Laden/Linken von db++Librairies von Standard Tcl oder perl aus zu ermöglichen
1995 Entwicklung der ODBC-Schnittstelle, zunächst auf Basis der netzwerkspezifischen API's fur PC-NFS, Chameleon, FTP, Novell Lan Workplace; Portierung von db++ auf DOS, Windows3.11
1994 Programmierbarkeit des dbServers mit Tcl, mehere dbServer laufen paralell, Einführung des Freeze-Konzeptes mit der Möglichkeit zusätzliche Bitvektoren im Rahmen des Schattenspeicher-Rollbackmechanismus mit dem Ziel zu nutzen, langlaufende Queries und inkrementelle Datenbankzugriffe zu koordinieren; Portierung auf Linux
1993 dbtcl, Entwicklung der Schittstelle zur Scriptsprache Tcl von Prof. Ousterhout; Uniqueoption für die kompakten Sekundarindizes, Logging Facility fur Roll-forward-Restaurierung; Umstellung von CITAT/X auf Tcl/Tk, Programmierbarkeit des dbServers mit Tcl
1992 Speicher- und Query-Optimierung
1991 Die aus den Untersuchungen des Vorjahres hervorgegangene RPC-Version des dbServers ermöglicht u.a. Netzwerk- und Multiuserfähigkeit sowie Endian-Kompatibilitat; Update für alle wichtigen Unix-Rechner u.a IBM AIX, HP-UX, SNI Sinix, Sun Solaris, UnixWare, SCO V.4, Linux, Data General, Motorola PowerPC und 88k, Silicon Graphics
1990 Umfangreiche Untersuchungen mit dem Ziel den dbServer netzwerkfähig und noch schneller zu machen (RPC, sockets, semaphores, shared memory)
1989 dbperl, Entwicklung der Schnittstelle zu perl - der Scriptsprache von Larry Wall - ursprünglich nur als Alternative zum db++eigenen Reportgenerator dbrpg, inzwischen wird dbperl jedoch von einigen Anwendern als bevorzugte Programmierschnittstelle für eigene Applikationsgeneratoren wegen der daraus resultierenden hervorragenden Customizing-Fähigkeiten verwendet
1988 Kompakte Sekundärindizes, zusätzliche Locking-Facilities auf Tupel/Datensatzebene, Portierung auf eine Vielzahl weiterer Hersteller und Unix-Versionen u.a. IBM AIX, NCR Tower, Olivetti V.4, Interactive, Generics, SCO Xenix und Unix
1987 Entwicklung des Retrievalsystems CITAT/X auf Basis von db++ durch Einführung zusätzlicher Invertierungs- und Suchmethoden;
1986 dbfsck, Programm zur Verifizierung und ggf. Restaurierung defekter Relationen, Portierung auf HP-UX und Sun OS
1985 Erste Client/Server-Implementation auf Basis von named pipes; Portierung auf Siemens PCX und PCS Cadmus
1984 Large Sekundärindizes, zusätzlicher Datentyp Deutsch für die Textfelder mit variabler Länge, Portierung auf DEC Vax und Kontron

Zum Anfang

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