views:

152

answers:

1

I will have multiple tables used by different projects on the same mySql server. Much of the data is sensitive, and needs to be behind permissions wall. However many of the tables of sensitive data rely on tables of insensitive data for user and department information. So I see three options ahead of me and I am unsure which one to pick.

All in one database with table level permissions

The simplest of all solutions except I don't control permissions on the database server, traditionally the server team only does database level permissions and getting them to allow it is a political battle I may not have the influence to win, and keeping track of all the permissions would be a pain.

In multiple databases, with database level permissions

I can split the tables into database zones, so department wide info, like the staff data, can be in it's own database and tools that edit the staff data can have UPDATE&INSERT access to the department database. Other tools would want to access parts of the staff list, the public staff directory have SELECT access to the to the staff tables, but pars of the staff tables would need to remain private, like personal contact info, copy codes, or billing indexes. I would need to split the staff tables into public or private tables, but I would be stuck with table level permissions again. So I would need to split the department database into the department shared and the department private databases.

Cross database views I would create views in a database that pulls data from other databases that the account does not have access to. So I can put all the staff information in the department database, then create a view in the web database that only pulls the columns that should be publicly available (name, department, extension). This would allow me to, in effect, have column level SELECT rights without having to muck about with permissions. My concern would be speed. The original table the data is being pulled from would be fully indexed but the documentation seems contradictory whether or not the columns would be indexed when querying the view.

Has anyone else used any of these three options? Do you have better ones that I haven't thought of? What are the pitfalls you can see beyond what I have pointed out for any of the options?

A: 

Views and stored-procedures are your best bet. Views can be used to provide generic access, but if some queries under-perform, re-write them to use stored-procedures bypassing the view for performance.

Martin
Will stored procedures also cross the permissions barrier that I can set up the procedures with a high account then view the data with a low account?
tvanover
yes - one of the main features of stored procedures is that they allow better management of privileges. The account that the stored procedures are defined under would be better as a local account - eg 'sp_owner'@'localhost' - to reduce the risk of a remote user getting powerful access under the account if they crack the password. The most flexible arrangement is if your stored procedures are defined as "create definer=current_user procedure ...", then the decision of which account they are defined under can be deferred until load time.
Martin