|
|
Posted by --CELKO-- on 09/07/06 19:17
>> There are a lot of reasons someone might want to create a table on the fly. They might want to store a snapshot of data at a given time that is easily accessable. <<
>> It may not fit your ideal of how SQL "should" be used, but it's actually quite common in the real world - and it need not invoke images of falling pachyderms. <<
Good RDBMS programming and principles are not my personal opinion; you
can read Dr. Codd, Chris Date, Fabian Pascal, McGovern, etc. for the
foundations. Erland just told the guy the same thing, but without any
details to help him learn. Why not jump him and rant?
>> Sometimes it's just convenient to make a temp table. <<
Yes, it is. It is also just convenient to use a copper penny instead
of getting a fuse from the hardware store.
>> He told you what he wanted - the "problem" is your inability to understand that most people use SQL in ways that go beyond your precious standard. <<
No, there was no problem statement. As Chris Date puts it in a book
title of his, we need to hear "WHAT" and not "HOW" to have a spec.
Also, I think that after seven books on the language and ten years on
the Standards Committee, I have some understanding of SQL :) What are
your credentials?
A problem statement is "my bill of materials is a hierachy and I need
to aggregate the weights of the components into the sub-assemblies"; it
is not "How do I create a temp table {assumed method} to aggregate
the weights of the components into the sub-assemblies"; that is a
method and not a result. Now we can come back with the nested sets
model, or adjacency list model with a recursive CTE as a suggestion for
the hierarchy, and avoid a temp table completely. Ask "WHAT" and not
"HOW" -- basic software engineering. Hell, basic any kind of
engineering!
Navigation:
[Reply to this message]
|