A Client has a huge Windows Application running on a Database. This client wants you to develop an "Express" version of this application, including only, let's say, 20% of its features. This Express version must be a Web Application, opened on the WWW. You have 2 choices:

  • Use the same Database to develop the web application
  • Create a new database to the web application, including only the necessary tables and objects and use some synchronization mechanism to keep the databases up to date.

The client prefers the 2nd option, because:

Security: If they have a separated Database for the web app, they will not "expose" the huge Windows App Database on the internet.

Performance: The windows application has some huge process that they run at night and "lock" the database for a couple of minutes. So, creating a separated DB would ensure better performance to the web application.

I prefer the 1st option, because:

Integrity: If we have different databases, we won't be able to create Foreign Keys between them.

Avoid Sync: If we have different databases, we would have to create a synchronization mechanism, which is very prone to failures.

Maintenance: Maintenance will be easier if we have only one database. No change will need to be replicated.

Can you help me decide which way to follow, and why?

  • Can you give some additional context on the nature of the web app? Are you taking orders? Allowing self service updates to personal details eg phone and address? – jasonk May 28 '12 at 22:00

I'm inclined to agree with you for the reasons you state. Also, if you use the same database, you also get a very practical business benefit - you can easily 'upgrade' a customer to the full version without a complicated data export/import.

One thing you might recommend is trying it first with the one database approach. If that becomes a problem, its far easier to then separate the 'express' data into a new database than it would be if you started off with two databases but later decided to merge them.


I agree with the 1 db option as well, for additional reasons.


You can record actions taken via web client vs. the app client and report on it. Usage metrics like this can be very handy.


Having the app and web DBs out of sync for however long the sync timespan is can be a pain for users, depending on the sync strategy.


It'll be plain-old cheaper to not write a second DB.

Time To Market

If they already have a service layer, then you're gold, use that. If not, then you can create one to wrap the libraries/functionality that already exist and you have proven, tested, production quality codebase backing the service(s) - and it doesn't need to change to hit a new DB or schema.


"The client prefers the 2nd option .. " Therefore it's not a technical problem anymore. The client has spoken, he has a right to tell you what to do (and he accepts responsibility for that choice). If you don't do what the client asks, you have to accept responsibly for the choice, and not doing what your client has asked is not good business practice.

  • 1
    However, if you know of serious disadvantages do doing it the way they ask, it's good to explain that before you just do whatever they ask. – Philip May 28 '12 at 22:53
  • 1
    @philip - +1 - agreed, just blindly following customer preferences can result in things like "Airplane wings cost money. In order to save money, we're not going to put wings on the airplanes" – Clockwork-Muse May 29 '12 at 18:21

If I got you right, the goal is to have one pool of consistent data for both the client application and the web application. Easiest solution is obviously one DB, and as you wrote, a two-DB approach needs a sync mechanism. But let's for a moment think about two-database approach to see what you did not mention in your list:

  • instead of creating a DB with a different schema, one could create a second DB with the same schema, a copy of all the data, and use the builtin replication mechanism of the MS SQL server. This way, the synchronisation gets much easier and less error prone.

  • integrity / foreign keys: if you use replication, this won't be a problem: all the data to be referenced is available in both databases

  • availability and network speed: that is the key thing when thinking about one db versus two. Two databases can be hosted at different sites, with different networks attached.When one server is down (or locked because of some batch process), the other one can still work.

So I recommend to think mainly about the last thing: do you need an increased availability provided by a two database solution? Or shall those two databases always be kept on the same site, perhaps on the same server? Then the "one database" solution is probably the better solution.


I fully agree with @SnOrfus that the "Create a new database to the web application" is the more expensive solution.

If this is not an argument for the customer as @mattnz suggested you may have an interim solution by refactoring parts of the solution into a common library that contains code that is necessary for both. This way you can at least reduce the maintanace nightmare.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.