I recently did a project with a developer who wrote a desktop app. This is used by a few businesses, and each business has their own database installed locally. The app does not use any Internet connection, and each business is completely independent of each other, they are just using the same code.
They then wanted a web site, which would allow their customers to log in and see some details of their accounts. Again, each business wanted their own web site, nothing to do with each other. As the developer doesn't have any experience in web development, he asked me to do it.
In order to keep development costs down, we agreed that I would develop one web site, and then deliver business-specific CSS files (based on the domain name), so that from the outside they would look like completely different web sites, although under the covers they would be using the same code.
Now, as the businesses have local databases, the web site couldn't use those for data. These databases are pretty large, with a lot of tables, each of which has a lot of columns, and contain a lot of data. The majority of the tables, columns and data is not relevant to the web site, so I suggested having a web service on the site, and the desktop app would post data to the web server as it was relevant, and the web server would save it in its own database. That way, the web server would have only the tables, columns and data it needed, and could store the data for all businesses in one database (marked with a business ID of course), to avoid having to handle multiple databases.
The alternative to this was to replicate each business's database in full on the server, and have the web site connect to whichever database was appropriate, ie depending on which business's web site was being displayed. The web server logic would also be a lot more complex, as it would need to distinguish between data that was to be displayed on the web and that which shouldn't.
I chose the former route, and implemented it. This worked fine until recently, when the amount of data being posted to the web service caused some problems. Whilst discussing the best way to solve those, I got an email from the author of the desktop app, in which he said (words in square brackets are mine, for clarification)...
the real issue is that the entire structure is not as it should be. their [the business's] database - mysql should be hosted online where they and those who log in all can access it. there should be no need for sync [posting to the web service]. this is how it is done properly. this is what i have recently managed to find out. i only wish you would have agreed on that originally. unfortunately i just accepted whatever you told me then at face value.
Now as far as I understand it, there is no "how it is done properly" when it comes to database and software design. Every situation has to be taken on its own, and the most appropriate solution for that situation used. In this case, it seemed inappropriate (in my opinion) to replicate each database in its entirety. I felt that then, and still think that way.
However, he has been told that this would have "how it is done properly" and is convinced that I did it incorrectly. He claims that this is the cause of the problems we are having.
In all fairness, had we gone down the full replication route, we wouldn't have had the current problems, but we would probably have had other problems in their place.
Any comments? How would you have done it?