Environment versions
Network:
Windows 2003 Server
>Hi,
>One of our developers has developed a trigger which does the following.
>
>1) A web app is running built in .Net instead of having the user press refresh to update he decided he want it built in a "push" manner so.
>2) He maintains a indexing service on a seperate machine that keeps an index (also build it .NET) and it has a web service interface to update the index.
>3) whenever a record is changed it sends a request to the web service to tell it which record is changed to update it.
>4) the back end is db2/sqlserver/oracle so he built a trigger on every table that calls the web service to notify changes to the indexing service.
>
>If I run an update which updates 80 records than 80 calls to the web service is made this takes about 13 seconds (the update time with the web calls is under 1 second).
>
>I'm not really keen on this design does anyone have any suggestions about how to convince him this is a bad idea or any alternative ideas.
>
>Thanks Tim
The performance degredation should be enough to convince him it is a bad idea.
An alternative - and a more correct way of solving the problem - is to use MSMQ Microsoft Message Queue instead of a web service. However, creating a notification trigger on every table is still a very bad idea.
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only