Challenge: All of the user management database tables come out of your application to be the guts of a single sign-on service which your app and a new app will use in tandem. How will you crosstalk between your app and the tables? Will you now hand in a username to get a user? It's been pointed out to me that in-house you can just keep using the user ID. The database tables which had constraints tying the IDs to the users table in foreign key columns will have their constraints broken, but there is really no reason why they can't just keep using the IDs for the lookups against the service. Keep the columns full of IDs! If this wasn't going on in your own little Petri dish and two very independent applications with different keepers were talking you wouldn't use an esoteric encoding for lookups, but if it's all in-house, why not?
No comments:
Post a Comment