Taxir, the first column oriented database, in 1969 paper

In another thread (on Alterian) Nigel Pendse and others discussed the
idea of a column oriented approach to storing data.

This "column oriented" approach to database is very old, dating to
before 1969.  On my home page http://home.comcast.net/~tolkin.family I
have put a copy of a paper that is the earliest description of this
technique.  Here is the start of that page:

Tolkin talking -- Software and Speculations

Highlights -- Bitwise storage in databases

The TAXIR system was probably the first database to use bitwise
storage. The bitwise storage technique is similar to bit-map indexes,
in that each item is represented using bits, rather than a sequence of
contiguous bytes, as in most conventional databases. They also share
the common characteristic that the data is organized by columns
(attributes), rather than by rows (records). The key difference is
that in bitwise storage there is only one copy of the data, whereas a
bit-map index is another physically stored access structure (the
"index") in addition to the storage used for the "base table".

Several modern systems including Sybase IQ and Nucleus use this
technique, which can dramatically improve performance by reducing both
space (memory) and time. In fact both Sybase IQ and Nucleus have been
granted patents in this area. But the basic ideas date back more than
thirty years.  Another very early system that used bit-map indexes
(although not bitwise storage) is Model 204 from CCA, which is still
being used today.

"The Theory of the TAXIR Accessioner" by George F. Estabrook and
Robert C. Brill was published in Mathematical Biosciences 5 (1969)
pp. 327-340.

...

Then I provide links to the actual paper in several formats: HTML,
Postscript, and Word.


P.S.  I posted this paper, the earliest to describe these techniques,
so it would not be lost.  I believe it is is historical importance.
Unfortunately when my home pages were moved from
home.attbi.com/~tolkin to http://home.comcast.net/~tolkin.family all
the links were broken amd so it is no longer found by Google and other
search engines.  So on a personal note, if people can link to this
page so Google etc. can find it again, I would appreciate it.


Hopefully helpfully yours,
Steve
-- 
Steven Tolkin    Steve . Tolkin at Fmr . Com   617-563-0516 
Fidelity Investments   82 Devonshire St. V4D     Boston MA 02109
There is nothing so practical as a good theory.  Comments are by me, 
not Fidelity Investments, its subsidiaries or affiliates.


"Nigel Pendse" <[EMAIL PROTECTED]> writes:

> I'm not really an expert on COP databases, and it doesn't help they don't
> use consistent terminology, but I think that Aleri, Sand, smartFOCUS, Sybase
> IQ, Synera, etc probably come into the category. But that doesn't mean that
> any are exactly the same as Alterian, as each approaches the problem in a
> different way.
>
>
> "IanS" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Thanks Nigel. Your reply has cleared a few things up for me.
>>
>> Can you list a few suppliers of COP databases please. Search engines
>> are struggling with the Column-Oriented
>> Technology description.
>>
>> thanks
>>
>> Ian
>>
>> "Nigel Pendse" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> CBAT is Alterian's name for I what prefer to call Column-Oriented
>>> Technology, or COP.  It's not a methodology but a type of optimised
>>> database. Alterian's implementation is proprietary and unique, but
>>> there are a number of other COP products available that do a similar
>>> job. So, to answer you question, you can buy other databases based
>>> on similar principles, but they won't describe themselves as CBAT as
>>> that's Alterian's own name.
>>>
>>> You can think of COP as being a category of high-performance
>>> products that are used for the analysis of large volumes of
>>> transaction information, in the same way as MOLAP is used for the
>>> analysis of multidimensional data. Both categories use special,
>>> highly-optimised databases that, for the particular apps for which
>>> they are intended, are far faster and more functional than
>>> general-purpose alternatives such as relational databases. But this
>>> doesn't man that COP and MOLAP are rhe same thing.
>>>
[rest snipped]