I don't think the article by the DB Guy is stating there are only two methods of creating a temp table
I began with "Is there another way to interpret the following quoted text from the site?".
However, the need to use temporary tables cannot be avoided sometimes. In those cases,
there are two main approaches to creating and populating a temporary table.
OK, I guess he's right because creating a temp table def would not, I suppose, be a "main" approach.
A temp table def would likely not be practical, but the point I wanted to make is that if it was practical in a particular case, it causes no bloat whatsoever. Once the procedure finishes, the table is gone and never existed anywhere but machine memory.
The same sort of bloat is generally accepted to be expected when continually creating and deleting temp queries. Here's where the temp query def certainly has a practical use. In fact, I'd use that over continually creating and deleting a table (or stored query) any day, because it too resides only in machine memory. Note that none of what I'm saying here has anything to do with db file size growth as a result of adding records. AFAIC, that's not bloat and I think it would be better if we didn't refer to normal file size growth as bloat. In fact, it would serve us all better if we had a more suitable term for "temporary table", because there's nothing temporary about the table per se.
Last edited by Micron; 03-18-2019 at 09:30 PM.
Reason: clarification
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.