[dba-SQLServer] Just an FYI

I think it will work too.

On 12/8/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> And I am not expecting one, from you or anyone else on this list.  I think
> that Arthur has presented a possible solution.  I think I am going to
> break
> this down into 6 or so different result tables, each with data from a
> consecutive range of fields across the big (wide) table.  I need to build
> a
> little "query generator" anyway to write queries for me, and if I add a
> field to my field lookup table to hold which vertical table the field is
> held in, then the query generator can write the query to pull data from
> the
> correct table.  That has some advantages and few disadvantages.  The
> storage
> tables hold fewer data elements so the scan for any given field is
> automatically faster.  It turns out that the data is grouped such that my
> client asks for fields "close to each other", i.e. they tend to come from
> the same survey.
>
> Thinking about it in that manner I think I can get this thing pretty fast.
> Essentially the wide table gets riced and diced and "partitioned"
> vertically, each vertical partition being N fields wide, but with the
> advantage that the resulting "vertical" tables hold only the records that
> actually contain data elements.
>
> I am running a program I wrote that builds up this vertical table.  I just
> told it to stop at field 83 which is the end of a logical group.  That
> will
> be the end of one table.  The next table will start at field 84 and go
> to...
> not sure yet but the same idea.  I think this will work...
>