Re: Sybase and materialized views


"Galen Boyer" <galen_boyer@xxxxxxxxx> wrote in message
news:ud5jzotc4.fsf@xxxxxxxxxx
> On 14 Dec 2005, sybdba@xxxxxxxxx wrote:
>> Since this work seems to be dependent on committed work on tables, the
>> equivalent could be done in ASE by using ASE Replicator (or full blown
>> Rep Server).
>> You can write all the procedural logic you want and update any tables
>> you want, using this event based mechanism,
>
> I guess you could. I'll take your work on it.
>
>> so what is the big deal?
>
> Well, in Oracle, Materialized Views are used by many people when the
> need fits their environments. That is quite a bit different than
> someone saying, "you COULD do such and such". So the question is, do
> you do what you are proposing? Is it something that is easy to do?
> Have you proven it over and over and never even had to debug it? ...

As I have implemented a materialised view using triggers only a few month
ago, I have had some thoughts on this.

First, we decided on a materialised view because the SQL-command for the
normal view would have become quite complex and we feared poor performance.

Secondly, maintaining the materialised view as quite simple, because there
was a one-to-one correspondence between rows in the view and row in *one*
other table. Furthermore the only update ever necessary on the view would be
on a status column matching exactly an equivalent column in the other table.

If on the other hand, the view is based on a number of other tables, each of
may have data inserted and updated independently, I would be more wary of
such an undertaking. The complexity of the maintenance could be great
indeed, even without considering problems with multithreaded updating:
syncronisation, locking, etc.

Regards,
Kristian Damm Jensen


.