Re: using table name as input parameter in SP?

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: GSK (gsk_at_NiOcSaP.nAeMt)
Date: 06/11/04 

Date: Fri, 11 Jun 2004 10:50:17 -0400

Geez, the slack that I have received has motivated me to re-architect the
data portion of the solution, and I no longer need the dynamic table names.

Unfortunately it is time taken that I will not be able to bill for, but I
expect to make the time back over a number of campaigns. (hopefully)

I promise I'll never advocate taking the easy road again. :-)

(However, the approach of taking shortcuts to get the job done is apparent
in virtually every piece of software that we use, and is often the
consequence of tight timelines and budgets. In a programming utopia these
would not be issues, but in reality, they are.)

-gsk.

"Joe Celko" <jcelko212@earthlink.net> wrote in message
news:uJOzTV1TEHA.3984@TK2MSFTNGP09.phx.gbl...
> Your "one table per campaign" design flaw is called attribute splitting.
> It is usually the first design flaw in an event cascade that leads to
> wanting to pass table names as parameters.
>
> >> Do you think the 'correct approach' would take less work? <<
>
> Just a rough guess, based on a decade or two cleaning up crappy
> databases, I'd guess with about 1/5 to 1/10 the effort until I have
> better specs. The code would be portable and maintainable, too. You
> could follow each person from campaign to campaign and do stats on them.
> Etc.
>
> Basically, your approach is to handle the problem as if you never did it
> before and will never do it again.
>
> "Against stupidity the gods themselves struggle in vain." - Die Jungfrau
> von Orleans; Friedrich von Schiller (1759-1805)
>
> --CELKO--
> ===========================
> Please post DDL, so that people do not have to guess what the keys,
> constraints, Declarative Referential Integrity, datatypes, etc. in your
> schema are.
>
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it!