Database Design - Better to Transmit Data or Store it, For Future Comparisons

[OldReliable]

First off, sorry about the title. My question is somewhat detailed and I couldn't think of an apporpriate title. This is my first post here. Anyway, I have a disconnected C# Winform application, using XML locally and SQL Server on the network as the datastore. We have an announcements piece, where local users here create announcements that our disconnected users can download at their convenience. Now, to ensure that there is no repitition, the disconnected users send a DataSet containing the IDs of the items that they already have, via a web service, and SQL Server fills in the blanks. This process is rather time consuming. Would it be better to store the ids of the ones that the user already has in a SQL Server table on the database server and then simply send the new ones the next time the user makes a request? There are 300 disconnected users and roughly 50 announcements created monthly, so that table could grow rather large rather quickly. Any other better solutions?

Thanks,

[Shaggy Hiker]

It sounds like you have the options covered. If you don't want the cost up front, you need to cache whatever you can to keep the speed up. It also sounds like this will work for you. The only issue you mention is the growing size of the SQL table. However, it seems that the Server table is only a speed enhancing data cache, rather than a long-term storage vessel. If size is the issue, wouldn't it be possible to date the items, and drop all items after x amount of time?