Subject | Re: [Firebird-Architect] Counter proposal to Temporary tables |
---|---|
Author | Alexandre Benson Smith |
Post date | 2004-11-30T21:49:53Z |
Aage Johansen wrote:
it to the filtered view, there isno chance to one user see others data,
or mess up with them.
I am following this thread, I really agrees with Ann, the temp table
proposed will be like what users do today, with some automagically
functions. Don't know how it is difficult to implement or not, but IMHO
this could be priorized down, since the user could get the same
funcionality with normal tables/views.
I have used Temp tables in MSSQL (6.5, yes, a really old one), the only
thing I like in it is that I could create/drop it inside SP's and the
definition/data is only seem by the user/connection. I think a permanent
temporary table don't bring us a big advantage over what could be
achieved today. But as explained earlier is this thread and on other
threads, metadata coud not be visible by only one user and it could not
be done in FB today (or in a short timeframe), and it's against what
standard says. So I don't really think that a Temp Table as proposed
(standard defined) is a must.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
>Ann W. Harrison wrote:If one revokes the select/insert/update/delete rows from table and grant
> > Given that we've largely agreed
> > ...
> > why do we need temporary tables at all? Why not use
> > a conventional table with fields defined to contain
> > the connection identifier and the current date? Those
> > two fields can be filled in with triggers. Create a
> > view that excludes the connection and date and filters
> > on the connection, and you've got a temporary table,
> > lacking only cleanup. Use a simple procedure that
> > filters on the date field from time to time to remove
> > data more than two weeks old.
> >
> > Not perfect, certainly, but free, and doesn't involve
> > mucking with internals at all.
>
>
>With "conventional table" one will need well-behaved clients who won't
>read/change or otherwise muck around in data that doesn't belong to them.
>
>
>--
>Aage J.
>
>
>
it to the filtered view, there isno chance to one user see others data,
or mess up with them.
I am following this thread, I really agrees with Ann, the temp table
proposed will be like what users do today, with some automagically
functions. Don't know how it is difficult to implement or not, but IMHO
this could be priorized down, since the user could get the same
funcionality with normal tables/views.
I have used Temp tables in MSSQL (6.5, yes, a really old one), the only
thing I like in it is that I could create/drop it inside SP's and the
definition/data is only seem by the user/connection. I think a permanent
temporary table don't bring us a big advantage over what could be
achieved today. But as explained earlier is this thread and on other
threads, metadata coud not be visible by only one user and it could not
be done in FB today (or in a short timeframe), and it's against what
standard says. So I don't really think that a Temp Table as proposed
(standard defined) is a must.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br