这个问题我也想过!听说有一种叫长连接的东西能做!但我也不知道是什么!
我所能想到的和你的第一种方法一样,使用js写一个程序,不停的请求数据库,但这样确实会给数据库造成压力!
我想过一个方法来解决这个问题,当发送方发送消息的时候,在服务器上生成xml文件,接收方的js文件,一直去找是否有新的文件(可以根据接收方userid+日期)等方式,如果有的话,就呈现消息!
这种方法我没有验证过,你试试吧!

可以看一下观察者模式方面的资料

另个 如果是轮询的方式的话，关键得分析一下你的程序，看取一个多大的轮询时间比较好。

触发器不要用了，程序轮询（扫描）并没有什么问题

比如3秒钟检测一次，这个时间对于用户来说应该是可以忍受的，3秒钟一次数据库操作没有任何问题，你可以这样算，页面每一次打开多数情况下都需要访问数据库吧，如果有三个人在线（这已经很少了），那么一秒内非常可能超过5次数据库访问，但你的程序和数据库在这种负载下显然不应该出现问题，所以你3秒一次轮询不会有问题，甚至1秒一次的轮询都没有关系

数据库没有想象的那么脆弱，呵呵。想想那些没做缓存上千人在线的网站，一秒钟上百次数据库访问并不会有什么问题

其实网站的站内短消息真正的问题不在这里，而在于如何及时通知用户，因为你无法主动发消息给浏览器，所以只能在页面中通过ajax或者iframe不停的请求服务器，每个打开了页面的用户都需要不停的发送请求，这才是真正的性能问题所在。（C/S类的IM没有此问题）

公司的商务通产品就是使用的AJAJX刷消息。

个人觉得轮询比较好

目前的应用是这么写的，大概情况是用户在页面上提交了信息，后台服务端程序（一个或多个）轮询数据库，发现有新信息，先标记自己拿到了，再采取操作。轮询大概1秒一次，比较温和了，如果是一次询问发现了新纪录，则当此执行完后无条件进行一次询问；若未发现，则延迟1秒轮询。目前没发现什么性能诟病。

如果用多个后台服务端程序，需要控制好并发问题，应该超出本帖讨论范围了吧。

@飞阿飞

丁学兄的说法并不矛盾，可能是你理解有点偏差。

丁学的意思应该是说服务端程序轮询不是问题，问题是客户端并发大，不停发送请求。

你所谓的IM是WEB版的还WINFORM版的

ajax处理消息加入到queue中,然后后台处理,返回也是一样

SNS这个功能确实很有用.ajax好象在这方面确实是专长...