# C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

© 2006-2015 Andrew Cooke (site) / post authors (content).

## Novel DB tech

From: "andrew cooke" <andrew@...>

Date: Fri, 9 Sep 2005 21:16:15 -0400 (CLT)

(Novel as in new, not Suse).

This is a database that keeps a permanent record going back over time.  I
*think* that means that it would be relatively easy to synchonize
different databases so that they remain consistent over the long term even
though they have different short term changes.

Our project at work involves two databases that are physically remote.
Somehow they must contain "the same data" over time, although they can
have short term (days) differences.

I'm not for a minute suggesting we use this, but if synchronisation
becomes a problem later it might be worth investigating.  Since the
archive data is largely cumulative (we add images a lot more than we
change the data we already have) I don't think the size penalty would be
too great.

Herodotus - http://www.herodotus.biz/Herodotus.html

Some related discussion - http://lambda-the-ultimate.org/node/view/953

Incidentally, since this is the normal way data structures work in pure
functional languages, and since those data structures are typically trees,
and since XML in some sense describes a tree structure, you might be able
to get the same behaviour from an XML database...

Andrew

_______________________________________________
compute mailing list
compute@...
https://acooke.dyndns.org/mailman/listinfo/compute