Re: Pass table name as parameter in stored procedure

microsoft.public.sqlserver.programming

27 Jul 2006 10:44 PM

--CELKO--

>> Obviously, CELKO hasn't programmed very much either. <<

Just over 35 years in the trade. I have outlived many of my
programming languages :) That is why I recognize the re-invention of
old, failed techniques with new, modern tools.

>> I'm working on an application right now where I need to build temp tables on the fly. Why would I write a sp for each table that I want to build? <<

Wrong question. The right question is why anyone would build temp
tables on the fly in an RDBMS? Each table models a set of the same
kind of entities. This says that your data model was not complete and
now a random future user has to create these things you left out at run
time.

I would bet that what you have done is re-invent 1950's scratch tapes.
In the old days, we did not have cheap disk storage or very much main
storage, so we would write programs that performed the steps in a
process. The results of each step went into a scratch tape, where it
could be sorted or merged with other data or whatever. Then that tape
went to the next process step.

The IBM convention was to name the tapes with "yyddd" in their labels.
The built-in date helped the audit trail and let the 1950's COBOL
system create those labels. Just like you want to do with tables!!
Deja vu!

28 Jul 2006 1:31 PM

Tony Rogerson

> Wrong question. The right question is why anyone would build temp
> tables on the fly in an RDBMS? Each table models a set of the same
> kind of entities. This says that your data model was not complete and
> now a random future user has to create these things you left out at run
> time.

If you had any real industrial experience, actually coded for a number of
years instead of theorising and writing articles and books then you wouldn't
even ask the question.

In fact you are showing a bit of a double standard these days - I've seen
you use temporary tables yourself only last week; you've also written
cursors when there has been no need.

Instead of trying to shoe horn solutions into standard SQL, why not do what
we do in the industry and give efficient, scalable and practical solutions
with the toolset given.

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials

Show quote

"--CELKO--" <jcelko***@earthlink.net> wrote in message
news:1154040281.986196.219000@b28g2000cwb.googlegroups.com...
>>> Obviously, CELKO hasn't programmed very much either. <<
>
> Just over 35 years in the trade. I have outlived many of my
> programming languages :)   That is why I recognize the re-invention of
> old, failed techniques with new, modern tools.
>
>>> I'm working on an application right now where I need to build temp
>>> tables on the fly. Why would I write a sp for each table that I want to
>>> build?   <<
>
> Wrong question. The right question is why anyone would build temp
> tables on the fly in an RDBMS?   Each table models a set of the same
> kind of entities. This says that your data model was not complete and
> now a random future user has to create these things you left out at run
> time.
>
> I would bet that what you have done is re-invent 1950's scratch tapes.
> In the old days, we did not have cheap disk storage or very much main
> storage, so we would write programs that performed the steps in a
> process. The results of each step went into a scratch tape, where it
> could be sorted or merged with other data or whatever. Then that tape
> went to the next process step.
>
> The IBM convention was to name the tapes with "yyddd" in their labels.
> The built-in date helped the audit trail and let the 1950's COBOL
> system create those labels. Just like you want to do with tables!!
> Deja vu!
>

29 Jul 2006 3:29 PM

--CELKO--

>> If you had any real industrial experience, actually coded for a number of years instead of theorising and writing articles and books then you wouldn't even ask the question. <<

35 years is not enough industrial experience? Wow! I usually ask
that someone have 5-10 years of experience to lead a team.

>> Instead of trying to shoe horn solutions into standard SQL, why not do what we do in the industry and give efficient, scalable and practical solutions with the toolset given. <<

Gee, I did not know that professionalism is measured by how proprietary
your code is. I thought that the measure is how maintainable and
portable the code is. Cowboy coders were the ones that write highly
proprietary code that gives them job security at the expense of their
client or employer.

I know you do not have the expereince to write a book, but have you
ever consider READING one? Start with Dijkstra, Yourdon, DeMarco and
the foundations of the software software engineering. Learn why
standards are important.

Just a few weeks ago, DR DOBBS had a mention of C/C++ standards in the
auto industry. Thecompiler vendors have drifted from those horrible
standards you hate so much that instead of "solutions with the toolset
given", the users are having to "shoe horn solutions into standard C"
to keep from killing people, messing up millions of vehicles, etc. Gee,
do you think that portable and maintainable code might be "efficient,
scalable and practical" in such an industry?

29 Jul 2006 9:52 PM

Tony Rogerson

Wow - you are just so far detached from how we work in the real world its
amazing! Seriously, you need to address the big thing that is missing in
that 35 years and thats a proper training regime mentored by other
programmers; you can't expect to do a degree or whatever and suddenly call
yourself an expert....

No wonder you are only asking for $750 a day and even that I doubt you are
getting....

I was trained to practioner level in IDEF which I find seldom used nowadays,
I tend to use MSF instead and technologies around it.

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials

Show quote

"--CELKO--" <jcelko***@earthlink.net> wrote in message
news:1154186970.233905.160500@m79g2000cwm.googlegroups.com...
>>> If you had any real industrial experience, actually coded for a number
>>> of years instead of theorising and writing articles and books then you
>>> wouldn't even ask the question. <<
>
> 35 years is not enough industrial experience? Wow! I usually ask
> that someone have 5-10 years of experience to lead a team.
>
>>> Instead of trying to shoe horn solutions into standard SQL, why not do
>>> what we do in the industry and give efficient, scalable and practical
>>> solutions with the toolset given. <<
>
> Gee, I did not know that professionalism is measured by how proprietary
> your code is. I thought that the measure is how maintainable and
> portable the code is. Cowboy coders were the ones that write highly
> proprietary code that gives them job security at the expense of their
> client or employer.
>
> I know you do not have the expereince to write a book, but have you
> ever consider READING one? Start with Dijkstra, Yourdon, DeMarco and
> the foundations of the software software engineering. Learn why
> standards are important.
>
> Just a few weeks ago, DR DOBBS had a mention of C/C++ standards in the
> auto industry. Thecompiler vendors have drifted from those horrible
> standards you hate so much that instead of "solutions with the toolset
> given", the users are having to "shoe horn solutions into standard C"
> to keep from killing people, messing up millions of vehicles, etc. Gee,
> do you think that portable and maintainable code might be "efficient,
> scalable and practical" in such an industry?
>