Subject | Re: [Firebird-Architect] Counter proposal to Temporary tables |
---|---|
Author | Paulo Gaspar |
Post date | 2004-12-01T15:15:33Z |
I too agree that cleaning up first allows you to develop features better
and faster later
AND avoids further mess AND avoids making future cleanup harder.
But temporary tables are one of the features I miss the most. Temp.
tables are the
natural way of making somethings and having them native - instead of
using workarounds
to share tables - avoids a lot of administrative burden and clean up issues.
Not only do temporary tables make the developer work easier, but they
can also make
the DBA work easier too, since temporary tables - only existing at
process run-time -
never have to be administred. I.e.: the developer declares/creates them
in a given (group
of) stored procedure and they only exist "inside" that stored procedure
- nowhere else
and no one else has to care about them.
I used temporary tables with Sybase's and Microsoft's SQL Server and its
the ONE
feature I miss from those databases, especially because its convenience
and ease of use.
Regards,
Paulo Gaspar
Martijn Tonies wrote:
and faster later
AND avoids further mess AND avoids making future cleanup harder.
But temporary tables are one of the features I miss the most. Temp.
tables are the
natural way of making somethings and having them native - instead of
using workarounds
to share tables - avoids a lot of administrative burden and clean up issues.
Not only do temporary tables make the developer work easier, but they
can also make
the DBA work easier too, since temporary tables - only existing at
process run-time -
never have to be administred. I.e.: the developer declares/creates them
in a given (group
of) stored procedure and they only exist "inside" that stored procedure
- nowhere else
and no one else has to care about them.
I used temporary tables with Sybase's and Microsoft's SQL Server and its
the ONE
feature I miss from those databases, especially because its convenience
and ease of use.
Regards,
Paulo Gaspar
Martijn Tonies wrote:
>Jim,
>
>From: "Jim Starkey"
>
>
>>Martijn Tonies wrote:
>>
>>
>>
>>>Not having to run the clean-up procedure yourself is exactly
>>>one of the reasons why temp-tables are, well, not "needed",
>>>but surely very convinient.
>>>
>>>
>>>
>>>
>>>
>>I don't think it is a question of whether they are needed or not, but
>>whether how much they're needed, especially when compared to other
>>things on the plate.
>>
>>Personally, I think the priorities for developers should lean towards
>>cleanup of the internal infrastructure before we add more external
>>features. Things that I see are more important than temporary tables are:
>>
>>
>
>--8<--
>
>Although I agree with the house-cleaning, it's not what I read
>from Ann's message. I read "why do we need them while we
>can work around it".
>
>If it's moved to "way later" on the roadmap, fine. If house
>cleaning has the priority, fine. But just saying "we don't need
>this or that 'cause we can easily work around by doing so and
>so and so" strikes me as wrong.
>
>With regards,
>
>Martijn Tonies
>Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
>Server.
>Upscene Productions
>http://www.upscene.com
>
>