One large application or many small applications?

[eluser]jleequeen[/eluser]
Hello All,

I would appreciate some thoughts on the subject of application management. I manage 4 separate applications that I'm recoding using CI. Each of the employees at my job all use these applications. Right now everything is segmented and each application has there own user tables, databases, etc.

Since I'm rewriting these apps using CI, I am toying around with the idea to consolidate the databases and only having one user table, sessions table..etc. I've seen how CI can be used with multiple applications (each having there own index.php file) so that is an option now. I'm just wondering from real world experience whether it would be a good thing or not to consolidate these apps into one large app, or keep them small and separate. Some of the tables could certainly be shared, but the majority couldn't be. I guess the options I have are as followed.

1. One large app, one large database.
2. 4 small apps, one large database, 1 backend admin for all 4 apps.
3. 4 small apps each with there own database and admin section. Nothing shared.

Any ideas from anyone on there experiences with this situation? Thanks in advance.

[eluser]Popcorn[/eluser]
Personally I would stick to individual applications. It will help if you ever need to move the application to a different server. Also, with all 4 applications sharing the database you would have 4x the data in the sessions table than you would normally have if you ran them by themselves. This could affect the performance across the board.

[eluser]Tom Glover[/eluser]
Option number 2 would seem the best, as it would allow you to keep the apps separate, but still share data between them.

The single back-end, would make administration simpler.

Use one instance of CI for all 4 apps, and use HMVC or Sub-folders for the individual app separation.

[eluser]jleequeen[/eluser]
@popcorn

Yes, I was thinking about a bottleneck potentially across the board as well.

@WakyWebs.net

I'm leaning that way myself, just wanted to hear about others experiences and pros and cons.

[eluser]Jay Turley[/eluser]
At my current position, I spent the first two years developing many small vertical applications for our internal use, each with their own database.

I spent the next two years refactoring the code and databases, bringing all of those applications into one common cross-enterprise application suite running off of a single database.

The reason is that it became apparent over time that many of the items in each separate application were related to items in other databases. The first suggestion was to create an API for each application so that information could be requested and sent cross-application. However, this had such a low ROI that we eventually just bit the bullet and brought them all into one tool.

So, my advice is, if you can GUARANTEE that these applications will never need to talk to each other, and that you will remain perfectly comfortable with such denormalized/redundant data repositories, then what the heck, go the 4 app / 4 db route.

If - on the other hand - you feel that you might eventually have to relate some of this information to other pieces, it may be worth biting the bullet and bringing all the data into one database.

It doesn't matter if you have 1 or X applications accessing it. One database is the way to go in my experience.

[eluser]jleequeen[/eluser]
@jay

There are definitely ways in which these applications need to talk to each other. Particularly, some of the model between the apps could be shared. My databases right now are MySQL databases. Not real big either. 4 separate DB's with anywhere between 10-30 tables in each. Some of those tables would obviously be shared so if I refactored the DB I'd probably be looking at maybe 50-60 tables.

[eluser]Jay Turley[/eluser]
I haven't been working with CI that long, so I can't bring an experienced perspective from that point of view, but I will say that I am currently working on a new application which has four separate ways to view the content of the database. These different ways of accessing the data are so different that I have essentially broken it into four applications accessing the same database.

However, the only issue that really, *really* bugs me so far about it is when I have a User model, lets say, that code becomes duplicated across the four applications. The only way I can think of to resolve this is to move all four applications into one large one - similar to your problem. So I may eventually be forced to move in that direction to avoid the duplicated code.

Which, I guess, kind of indicates that maybe the one application idea may be the right way to go. Unless someone out there has a better idea for handling this sort of issue with CI.

[eluser]jleequeen[/eluser]
@jay

Yes, that bugs me as well. And the fact that some of the model for my apps could be shared leads me to somewhat of the same conclusion. Fortunately my apps are only accessed by a relatively small user base since they are so specialized, so I'm not really all that concerned from a performance perspective. Thank you for your experiences and thoughts. I've not been working with CI that long either, so any thoughts are great for me to hear. I really like CI a lot, and realize it can't fit every scenario, but I'd really like to figure out how to best make it fit with what I'm trying to do.

[eluser]jleequeen[/eluser]
@jay

Well here it is 5 months later and I'm beginning to work on a second app that I think would be more appropriate to have sharing the same database as the first app instead of separating them out. It seems to me that continuity is of main concern here and in order to keep that consistent between the databases it would be far better to have one database. What did you decide to do in your situation? It'd be cool to hear an update.

[eluser]Jay Turley[/eluser]
@jleequeen

I decided to have a single application. This enabled me to reuse the code, which was important to me since I didn't want to have to duplicate any of it.