Subject | Re: [Firebird-Architect] Counter proposal to Temporary tables |
---|---|
Author | Nando Dessena |
Post date | 2004-12-01T15:22:34Z |
Paulo,
P> Not only do temporary tables make the developer work easier, but they
P> can also make
P> the DBA work easier too, since temporary tables - only existing at
P> process run-time -
P> never have to be administred. I.e.: the developer declares/creates them
P> in a given (group
P> of) stored procedure and they only exist "inside" that stored procedure
P> - nowhere else
P> and no one else has to care about them.
P> I used temporary tables with Sybase's and Microsoft's SQL Server and its
P> the ONE
P> feature I miss from those databases, especially because its convenience
P> and ease of use.
the proposal this thread is about has nothing to do with Sybase's and
Microsoft's implementations nor with the advantages you talk about,
except perhaps the name. But that actually adds to the confusion,
instead of reducing it. ;-)
Ciao
--
Nando Dessena
http://www.flamerobin.org
P> Not only do temporary tables make the developer work easier, but they
P> can also make
P> the DBA work easier too, since temporary tables - only existing at
P> process run-time -
P> never have to be administred. I.e.: the developer declares/creates them
P> in a given (group
P> of) stored procedure and they only exist "inside" that stored procedure
P> - nowhere else
P> and no one else has to care about them.
P> I used temporary tables with Sybase's and Microsoft's SQL Server and its
P> the ONE
P> feature I miss from those databases, especially because its convenience
P> and ease of use.
the proposal this thread is about has nothing to do with Sybase's and
Microsoft's implementations nor with the advantages you talk about,
except perhaps the name. But that actually adds to the confusion,
instead of reducing it. ;-)
Ciao
--
Nando Dessena
http://www.flamerobin.org