smd@rehder.larc.nasa.gov (Steve Dahmen) (11/17/90)
rang@cs.wisc.edu (Anton Rang) wrote in "ndbm won't cut it, what now?": > Dbm/ndbm/gdbm works fine if you only have one key per record and >don't need the records to be ordered; for slightly more complicated >things, there's probably public-domain code floating around. For a >real relational DB, unless one can use University INGRES, I suspect >one would need to go the commercial route. > > Anton O good People of the Net - We here at Langley Research Center (NASA) are searching for a robust, (fairly) well-tested and documented relational db system to assist in the integration of a large number of applications 'extracting' data from a common db. We have a package that sits on top of 'any' database, providing a nice interface to whatever package we choose. It needs to be PD because we share our code with a number of universitites and research facilities, and cannot expect them to invest in ORACLE or INGRES or what-have you. We don't need a WHOLE lot of functionality - sorts are not critical. Just has to handle character, integer, float, double, and variable length arrays of each. Desired is the ability to specify a "WHERE" clause (ie all the records whose 3rd field is less than 50). I have the ftp-list, but many of the names are cryptic... perhaps indicating a db package??? Email me with any info you have, and I'll post a summary! Thanks for your input! Your Space Program Thanks You! <note: this is not an official thankyou> Steve Dahmen -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Steve Dahmen, Systems Analyst (804) 864-4519 (W) M/S 365, NASA Langley Research Center Hampton, Virginia 23665 smd@rehder.larc.nasa.gov
smd@rehder.larc.nasa.gov (Steve Dahmen) (11/17/90)
Oops - Forgot to include some pertinents: We be running this on an IRIX (SGI Unix clone) v. 3.3.1. It would be best if the DB was in C, with source. Thanks - -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Steve Dahmen, Systems Analyst (804) 864-4519 (W) M/S 365, NASA Langley Research Center Hampton, Virginia 23665 smd@rehder.larc.nasa.gov
mboen@nixdorf.de (Martin Boening) (11/18/90)
Hi,
after reading the answers to your question: I once saw a system of management
routines (b+tree) posted on the net which implements a library for building
DB systems. So you'd have to program you own DB system but you could use
the b+tree library to do it. Supposedly (i'd have to check in our archives
to see if I could check on what I'm saying here) the b+tree routines support
variable length records and multiple keys.
If you insist on dbm, an example implementation of dbm routines based on
b+tree was also delivered.
So maybe you want to check that out.
--
Email: in the USA -> mboening.pad@nixdorf.com
outside USA -> mboening.pad@nixdorf.de
Paper Mail: Martin Boening, Nixdorf Computer AG, SNI STO SI 355,
Pontanusstr. 55, 4790 Paderborn, W.-Germany (Phone: +49 5251 146155)mjr@hussar.dco.dec.com (Marcus J. Ranum) (11/19/90)
Martin Boening writes: >[...] I once saw a system of management >routines (b+tree) posted on the net which implements a library for building >DB systems. So you'd have to program you own DB system but you could use >the b+tree library to do it. Yeah, I wrote that a while back. The B+tree code is oK, and there was a lame attempt at record management code I wrapped with it that should not be used if you need speedy updates (I didn't when I wrote it). The B+tree code doesn't have built-in support for multiple keys (you don't want that anyhow) and allows you to just store a long value, presumably a disk offset or record (or indirect record block) number. There are a few changes that could be made to the B+tree code to speed it up slightly - I had a few revelations after I wrote it and don't want to attack it again :( (the current version is already re-write #4). You can get pretty decent access by taking a B+tree (or some other ordered search tree) that stores a record #, *and* a dbm database, and you store the key in both, with the record pointer being the dbm datum. You have to update them both, then, but it's plenty quick, believe me. The B+tree does at least support variable length keys and user-defined key types. The main reason I'd *NOT* recommend my code for writing a "real" DBMS is because there's no support built into the B+tree code for allowing concurrent update, or access while the tree is being updated, because of the way the code recurses down the tree (using an in-memory stack). Doing that kind of thing "right" is hard, and if you don't do it right, you've only succeeded in re-writing DBaseIII mjr. -- "When choosing between two evils, give preference to the council of your tummy over that of your testes. The history of mankind is full of disasters that could have been averted by a good meal, followed by a nap on the couch." -Me, as explained to me by my wife's cat Strummer.