Best architecture for an emergency alert system

I'm developing a software system which receives information (which is saved to a database) and when any information is received (new insert in a specific table) an alert should be seen in the screen in the information center, so proper action can be taken.

I'm writing an application with ASPNET MVC, SQL Server 2008 Express, SQL Agent free for that version of SQL Server, Entity Framework 4, Visual Studio 2010, etc.

Right now, I've set the database and 开发者_开发百科a SQL job that monitors the table each minute, if there is a new records an email is sent to same addresses. My problem is...What then? Which would be the best architecture to follow? A couple of option I thought about are:

1) In the job connect to a web service and that web service an the web service can open a popup 2) The web page could be pooling the database table to know if there are new records

Is there any way to make push to the web page instead of the page pooling the database server?

I know maybe windows application would fit better here, but right now I must stick with ASPNET MVC as I already started and don't want to create another application. Thanks! Daniel

Is there any way to make push to the web page instead of the page pooling the database server?

HTML5 WebSockets. Draft, pretty new, specification is still subject to change, to all browsers implement it. You will need a WebSocket Server. If you go that route make sure you read this guy's blog. He is behind Laharsub which is a must try server.

I'm pretty sure you are able to use Silverlight to push data down to the client. Here is a pretty good overview that I read a while back. HTML5 might be a better way to go. But with such limited support it's almost not worth it at this point. Granted the Silverlight application might be out of reach to, but it's still a possibility.

I would suggest that you look into (complex) event processing, or stream processing -- at least to get the feeling for architecture of these systems.

The idea is to capture a stream of events before they reach database, route them (process) within the event processor and put them in the DB from there -- treating the DB as only one of event destinations (subscribers).

Take a look at Streambase, ruleCore, and many others.

These were all developed for the type of scenario you described.

Try to see the problem from the other angle. Develop a web client that reads the database every minute and compare to last pull ...