Re: Theory of Timeseries extensions to SQL and database

From: Paul G. Brown <paul_geoffrey_brown_at_yahoo.com>
Date: 27 Oct 2002 19:44:29 -0800
Message-ID: <57da7b56.0210271944.343af261_at_posting.google.com>


71062.1056_at_compuserve.com (--CELKO--) wrote in message news:<c0d87ec0.0210271001.2dcc1f8e_at_posting.google.com>...
> The real trick in Nucleus is that they compress the sparse matrix in
> such a way that they can query it in its compressed form. The fact
> that 'red' is the color of car "#12" in race (7) becomes one bit in a
> compressed 3D bit space.
>
> In effect, all columns are indexed.

   I've seen this proposed as a design several times over the years (Sybase IQ   server used a flavor of 'vertical partitioning' too, and there are a couple of   systems out there (required technology?) that make extensive use of   clever compression schemes), but every time someone has gone this way the   resulting system has either sucked on updates, or else has imposed a raft of   'thou cannot do X' rules (transactions being the big out). Changing a   value requires a change in the physical location of the datum, resulting in a   cascade of changes throughout the physical store (references getting updated,   references to references getting updated. . . )

  I can't see any details on the design of the transactions manager from the   web work. Anyone got any ideas? Or is it pretty much a 'read only' system   (which is fine, BTW: there is a market for such products). Received on Mon Oct 28 2002 - 04:44:29 CET

Original text of this message