Re: Theory of Timeseries extensions to SQL and database

--CELKO-- wrote:
>>> Frankly that sounds a bit like marketing speak to me. <<
>
>I have worked with Kdb and the numbers are very good, very real.

I don't doubt their numbers. Just how fair their comparison is to other relational databases.

>>> Obviously reading the whole table into memory is going to be faster
>if it only contains the time series data you need, but you can get
>that arranged in any relational database. <<
>
>No, you assemble a table from columns (see also Nucleus from Sand
>Technology), so you only bring in the columns that you need rather
>than an entire row.

How is that different from creating a special table that is a projection from the original table?

>Nuclues goes a step further and stores domains, from which you built
>columns, then use the columns to build rows. The database can get very
>small and VERY fast for large volumes.

I'm guessing here, but I assume what you mean here is that you have a separate table for the domain and then in the original table you only store a pointer or some identifier that points to the actual domain value. In case the domain table fits in your main memory that will speed things up considerably. So what prevents me from arranging such a set-up in, say, Oracle?

• Jan Hidders