Posted by David Rawheiser on 10/22/05 23:32

Since I have worked in a job oriented shop before, (i.e. each class action
suit we processed was unique in some way and had differing on-the-fly data
needs) - I am not as strident as -CELKO- is here, but there should be a
commonality of design and process designed into each round, with those
'special needs' handled in seperate side car tables.

Rather than change the procs / scripts each and every time you need to
change the tables, (and make cut/paste search/replace errors) -
I would recommend creating views before each analysis session that point to
the set of tables in process.

That way the procs/scripts can refer to the same abstract table names (and
they can even be tempoary views if possible).

If there are differing columns each set, the view would pick them up if you
create it with a "select * ".


"Erland Sommarskog" <esquel@sommarskog.se> wrote in message
news:Xns96F7A574D71F3Yazorman@127.0.0.1...
> rola (rong.guo@gmail.com) writes:
>> I think i got myself a little bit confused... As I always use the
>> tables created by our DBA, I am not very familiar with
>> creating/altering tables, as well as the primary key (sorry). Here is
>> what i do now every month:
>>
>> --At the end of September
>> select A, B (A B would change every month)
>> into customer_20050930
>> from table_A (already in our database and will be updated monthly)
>> group by A, B
>>
>> --At the end of October
>> select A, B (A B would change every month)
>> into customer_20051031
>> from table_A (already in our database and will be updated monthly)
>> group by A, B
>>
>> I am wondering how I can apply what you suggested to my current query?
>> Could you please show me the query?
>
>
> If the tables can look different from month to month, then it is a little
> more tricky to use one table with month as key. Of course, you can alter
> the table to add or drop columns, but this may not be feasible.
>
> I would suggest that the best is to use any text editor with a
> find-replace
> functon to replace the strings. Since the queries change from to month,
> you
> need to edit anyway.
>
> The alternative is to use dynamic SQL, but that would make the script more
> difficult to maintain.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
>

[Back to original message]