Two similar applications on different domains but same users

Question

I'm planning on building two applications using Zend Framework that are very similar but serve two different purposes that can't be part of the same application or be combined into one. However, modules are something I'm considering.

The issue I'm running into is if a user registers for the first application I want that information be available to the second application, hence sharing a user table or user database. Because the applications are so similar that they have the same database tables with some having different fields, I'm not sure if I should have three, two or one databases. Three databases would be User Database, App1 Database, App2 Database. Two databases would be User Database and App1+2 Database with prefixed tables. One database would be User and App1+2 Database.

I'm trying to give as much information as possible, but because this is for a client I can't really discuss the details in depth. Also, this is something the client wants and other than not being able to figure out how to set it up, I'm not sure this is best.

My Questions

1. Of the options above, which would serve best, or other?
2. Should I have a shared user dataset across two applications or should the users have to register again?
3. No matter of the choice you think is best, how would/should I implement it into Zend? Just a brief is needed no need for code.

I hope this is enough information to give me the best answer, but if more information is need, please let me know.

Thanks!

Answer 1

Why have multiple databases? Use just one database and prefix the tables that differ for the two applications. For example:

users app1_otherdata app2_otherdata

This way users' data will be easily accessible to both apps and you could still have a relatively independent database structures.

Answer 2

Question 2 is something you really should discuss with your client.

Once you know your clients' preference you could eg. suggest using a single sign-on approach for the sites, but I would certainly keep both DBs apart. So either your 2 DB (with separate user DB per app) or your 3 DB solution (with separate user DB/single sign-on) makes more sense to me.