one app or many? (1 Viewer)

i have several applications - related by subject matter - that perform different functions. the apps were developed separately because they perform quite different functions and for other reasons.

but since these apps are "related by subject" most of these apps have similar or identical tables - the only difference is the number of rows. the number of rows in one (similar) table could be very different than the number of rows in another app's (similar) table because the focus of the app is different.

that means i often have to input the same data more than once; a few rows in one app, many rows in another app, possibly many rows in several apps.

this leads to the following scenarios and questions:

ONE APP
=======
i could **combine** the apps in order to share tables and other objects and have everything in one place. i would navigate through everything as one giant app or create what appears to be several different apps within the one.

problem: if i want to share an app (or what was once a single app) i have to keep track of which objects belong to which apps and be able to split them out. this is complicated and time consuming.

SEPARATE APPS WITH COMMON BACK-END
================================
- i could leave the apps separated but with a common back-end. to share an app i would recombine the appropriate tables (and rows). haven't done this but could figure it out i suppose.

problem: still have to open several apps to get things done.

LEAVE APPS SEPARATED
==================
- no change. just "deal with" closing and opening several different apps to do different things and entering the same data in different places. possibly figure out how to open one app from another. (any problems with opening *several* at the same time?)

problem: data redundancy.

===

not sure which scenario makes the most sense. all of the apps in question are currently single-user with no security issues. what would, or, what do you do with related apps?

edit: i hope it doesn't seem like i answered my own question by listing different approaches. i really don't know which way i should go with this. just wondering what people would do and why (briefly). replies don't have to get heavy into details.

If time is on your side, I vote for one app. Else the separate apps with a common-backend. Synchronizing data between two sources is generally not fun and can be complex to do programmatically.

I think that all things you want to manage that have the same data structure should be in the same table. Add various type fields if you need to. Arguments for a single DB as follows...
1) It's stupid simple, and fast, to write a query that returns a subset of records from a single table.
2) It's stupid hard, and slow, and prone to error, to merge data from two sources of almost identical structure where there may or may not be duplicate records.

Fourth option. Split your apps into front and back ends. Leave each app with its own backend unless the data is common with another app. Move the common data into its own back end.