开发者

Managing cross database reading, views or permissions in MySql

开发者 https://www.devze.com 2022-12-22 05:45 出处:网络
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

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 databa开发者_StackOverflow社区se 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?


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消