>So far, online stores I have set up were having the database on the server. I mean, the main database was on the server. So, basically, it was maintained thru the Web by the administrative interface.
>
>Now, I have a situation where the client as its POS system in the store, and that is the main database. So, basically, we have to duplicate that across the wire to the server. So, I will have a module installed locally which will synchronize the Web server every 15 minutes. This is good for up to a certain number of items. If the client has 10,000 items to sale, then, we would have to think about an alternative as synchronizing that across the wire, with the related images, would take a lot of time.
>
>So, the question is, when we have that much items, would it better to consider moving the main database to the Web server instead and having the POS application in the store reading the data from it?
>
>If this is not possible, what are the alternatives?

You don't mention the bandwidth between the web server and the store based SQL server but I assume it's slow enough to rule out accessing it directly from the web server. If that's the case then one copy of the DB in one location is always going to be a problem for one group of clients (IAC, as Al mentions I would be surprised if the company would accept a 'one copy on the web server' option).

In my experience (which may well not be typical) some things change more often than others. For example the actual product list may not change very often - but prices will. Also the main database will contain a large amount of data that is irrelevant to (or very rarely accessed by) the web site.
So how selective are you currently in the synchronization process? Obviously, for example, re-uploading an image when only a price has changed is not very efficient.

One approach is to not bother updating a web-site based DB unless the data is actually requested. Using your pricing example:
Record the DateTime the price of an item was last updated on the web server DB. When that item is next accessed check whether the update is recent enough and, if not, refresh from the main server.
You could look at using ASP.NET caching as an alternative to timestamping.

I also wouldn't discard Al's suggestion on replication without a closer look - I think it can be pretty selective and efficient about what actually gets pushed to the subscriber.....