2

This may be a question a little broad but... I'm currently having the following dilemma:

Having a web application (already deployed) and a new mobile app, I'm currently working on the mobile app database of the server side and my question is... Do you think it is better to have separate databases for the web & app, or is it better to integrate them in a single one?

I can think of pros & cons for every approach. For example, a single DB is easier to update and mantain. However, keeping them separated gives every app some sort of independence, allowing you to, for example, change the DBMS of any of them, if you need to...

I know it's a bit difficult to respond without knowing the databases design, context, etc. but what is your general thought? and what do the "big companies" usually do?

EDIT: Also, for example, if we wanted to scale up the mobile app in the future and migrate it to another server... would it be harder in any of the previous scenarios?

Improve this question
5

You can consider the web and mobile as just delivery interfaces to the functionality/services for your application. With this regard the backend functionality (server side - processing etc), should be the same for both interfaces, so yes they should have the same database.

You may want to add data to identify the sources of data addition or changes or traffic, but essentially its the same app.

UPDATE: Think of a mobile app just like a separate UI to be supported, I am not going to exhaust the possibilities but look at potential list of possible interfaces below:

  • Web Application - available
  • Mobile App - is this HTML 5 web app, Android or IOS? each may require its own 'different infrastructure'
  • Desktop app - for a subset, administration, operations
  • Web Services (REST, SOAP) - for machine to machine communication which does not have a definite UI per se, but may be provided to 3rd parties to develop their own apps (even the 3 UIs above can be considered as such)

The way to think about it is that there is one application with a single database which is being accessed through multiple channels, whether from the same server or different servers

Improve this answer
4
  • Agreed with ssmuskoe (+1). I would add that OP should ask themselves why they think the mobile app will be different from the web app? Wouldn't users of both expect the same capabilities? If anything, I would expect a mobile app to do a proper subset of the functions of a web app. In such a case splitting the underlying DBs seems like a bad idea. – Joel Brown Dec 17 '12 at 12:40
  • Nice answer! However, I have another option, please let me know your opinion about it: What about keeping them in separate databases BUT developing a procedure that keeps checking the already existing database and updates the new one? Pros: We keep independence among DBs and we just need to update one of them. Cons: As far as I have thought, probably the space, (constant processing?)... Also, I have another concern about this approach: my app retrieves the information through a Web Service... Would we have any trouble if a user made a request when the process is updating the new DB? Thank you! – Dhanesh Budhrani Dec 17 '12 at 18:42
  • Again I would still recommend having a single database, and in the serverside code (C# Java PHP) or whatever you are running add the functionality to ensure that the conflicts are handled. You will have a lot more trouble synchronizing databases than managing conflicts in the application layer – Stephen Senkomago Musoke Dec 18 '12 at 5:18
  • Yes, that's true. Better keep things simple... Thanks! – Dhanesh Budhrani Dec 18 '12 at 11:42

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.