Nigel Metheringham wrote:
> On Mon, 2006-04-17 at 11:54 +0100, Peter Bowyer wrote:
>
>>On 17/04/06, David Saez Padros <david@???> wrote:
>>
>>>the best option is just open a pipe to cdbmake and pass the ascii data
>>>to it ( see http://cr.yp.to/cdb/cdbmake.html ), you will have to
>>>recreate the whole table every time. As far as i know is not
>>>a good idea to modify the structure of an already created cdb database
>>>as (your have the specs at http://cr.yp.to/cdb/cdb.txt )
>>
>>Indeed it's not - if you need to update, use some form of dbm instead.
>>cdb is optimised for write-once, lookup-many - and cdbmake provides
>>atomic rebuilds.
>
>
> Long ago, the Freeserve system used to use a daily build of a cdb file
> for authentication because it was blindingly fast. However we needed to
> be able to add/change users etc so there was a second level dbm lookup
> used if the cdb lookup failed (the gdbm file, with locking, was roughly
> a factor of 10 slower than CDB)
I'll take a swag and guess that PostgreSQL would be yet-another
full order of magnitude slower... maybe two..
> - this was updated on the fly from the
> main database (I was, and still am, keen on semi-autonomous systems
> where service can continue even in the face of a major failure of the
> central database).
ACK. Applause from the back row here..
> Of course user updates gave us a little bit of a
> problem... easily fixed by nulling out changed users from the cdb
> tables.
>
Hmm... WORM approach?
> And so I claim the prize for strangest abuse of cdb files :-)
>
> Nigel.
Dunno, 'Strange abuse' might surely include my 1970's use of
'words' added to the Forth 'dictionary' that were merely the SKU
number of a product, and defined only the screen-number of the
first 1024-byte map in VM that held a BOM record for it.
Blitzen fast, even on 2 or 4 MHz Z-80 and 8" FDD.
Still have Pick's book around that inspired the approach...
Bill
