Amir.....
After all I have thought of 3 methods of integration. I would like everyone who have an experience to share it with me and vote for the best methd that comes to your mind :
I vote for number 1.
Unless you have some other reason to do a major rewrite, it seems the easiest to share the username and passwords across applications. It's nice to make things perfect, but sometimes you have to look at how much effort versus the return.
> Cons : Huge amount of data duplication as each username. password, address and other
> related fields will be the same in many databases! , High database loads due to multiple
> UPDATE of several tables in different DBs.
Yes, but disk space is cheaper than the labor, and time, of all that rewriting. And further, except for the added CAS table, it's no more than the space you are already using. No wait, that's not so, each table will have ALL the users now, not just a subset. Oh, well.
As far as updating, that only happens when a user makes a change, or maybe once when he logs in. And if it's too slow you can find a way to do it in the background, let the user set it in the CAS and be done, then find another way to propagate the changes to the other database tables. A trigger (maybe, not sure) or some recurring job that finds data that hasn't been propagated and does it, then sets a flag column for that user that it's been synced.
I'm sure others on the list can think of some more (maybe better) ways.
So I'm voting for number one. On the other hand, I can think of times that I've cobbled something together and then realized I should have taken the time to do it right in the first place. It's a hard call to make up front!!!
brew
