> If you want to have persistent users, enforce the logic that all > authentication and capabilities of that user ties back to the master > list, wherever you place it. Your users should be identified by a > unique identifier, an integer, for integrity and congruency. > > Another tip I would suggest is to have a unique identifier for EVERY > row of the database. You may hear some argument against this, but the > space of an additional integer in the database per record will save > you a LOT of time when trying to identify and reference unique > records. This is very important if you want to implement any type of > historical record keeping. I did take a DB design class. :P > Following the above two suggestions can save you a lot of time and > headache. Whether or not you can cross databases depends upon whether > or not you're using an application server that allows you to have > multiple connections to the database. If not, you will likely be Well, thats what the question was. Postgresql can't reference tables in different DBs in the same select statement. Someone told me mySQL can do it, but I don't like its total lack of foreign key/references constraints. I like DB integrity. :P > jockying your DB connection from one DB to another, saving the > information retrieved in local variables. I'd sooner just dump everything in the same DB. Which I suppose is what I'll be doing. I'm still concerned about dumping DB's. If so, I'll want to just dump tables that belong to a given app. Suppose I'll have to look in to proper table access control... What I don't get is what seems to be a total lack of security with psql. Anyone with a shell on the DB server can use psql to log in as any user, in particular the DB admin, and have free reign over the DB. How do I make the damn thing ask for passwords? :P