I'm working at a company where one team manages the databases and others use tables / views from there. From time to time, views get refactored which might break things for other teams.
Is it possible to protect some columns so that those cannot simply be renamed / dropped? Or at least have a log message telling the person who wants to do it that another team depends on it?
In Snowflake, only users with roles who have privileges to update a view by changing its definition are able to make changes on the specified view. If a specific role has privileges to replace view definition, there is no mechanism to stop them from renaming or dropping columns.
You can see the logs in QUERY_HISTORY function in Snowflake Information_schema. The functions gives extensive information on which user ran the query and the time it ran. A query like below would bring the appropriate information:
select user_name, role_name, query_text, start_time, end_time from table(information_schema.query_history())
where query_text ilike '%replace view %'
order by start_time desc;
The privilege to alter a view is all or nothing. It does not restrict which columns the role can or cannot alter, remove, add, etc. However, since Snowflake allows using views as part of another view, this can form part of your organization's overall approach to do what you're seeking.
For example, create a base view that has all the protected columns. Tightly control access to which roles can alter the base view. From the base view, create views on top that less privileged roles can alter.
Related
I am currently working in a SQL server database where I have a table User that has a schema like so:
username
category
user1
gaming
user2
gaming
user3
sports
My summary table UserCategoryCount is a simple groupby statement for how many users belong to each category and looks like this:
category
numUsers
gaming
2
sports
1
New entries are constantly being uploaded to the User, and I want to be able to stream updates in the User table to the UserCategoryCount summary table. I am aware that I can create a simple VIEW statement that performs a groupby on the User table, but I would like UserCategoryCount to be its own table that automatically changes based on new users being uploaded to the User table.
My first thought was to create a trigger that will detect when the User table has been updated. So far, the most simple but cheesy solution I can think of is creating a trigger that simply deletes and refreshes UserCategoryCount:
CREATE TRIGGER TRG_Add_User
ON User
AS
BEGIN
DELETE FROM UserCategoryCount
INSERT INTO UserCategoryCount (category, numUsers)
SELECT Category, Count(Category) as numUsers
FROM User GROUP BY Category
END
GO
But this seems like a really hacky way of updating the UserCategoryCount table. Any help on how to improve this update statement so that I don't have to completely overwrite the table every time a new user or batch of users has been inserted would be greatly appreciated.
For a start, your trigger is seriously flawed: it does not use the inserted or deleted tables and instead recalculates the whole thing every time, this is going to be very bad for performance. It also does not specify whether it is for inserts, updates or deletes.
A much better solution is to use an indexed view. This is like a regular view, except that the server maintains the actual data on disk, and updates it in real-time whenever there are changes to the underlying tables.
CREATE OR ALTER VIEW dbo.UserCategoryCount
WITH SCHEMABINDING
AS
SELECT
u.Category,
COUNT_BIG(*) AS numUsers
FROM dbo.User u
GROUP BY u.Category;
GO
CREATE UNIQUE CLUSTERED INDEX CX_UserCategoryCount ON dbo.UserCategoryCount (Category);
There are some restrictions on indexed views, among them:
They must be schema-bound, and therefore underlying columns cannot be changed
All tables must be two-part, schema and table
Only joins allowed are INNER or CROSS, no LEFT/RIGHT/FULL/APPLY or derived tables, CTEs or subqueries.
If there is a GROUP BY, you must add COUNT_BIG, and the only other aggregate allowed is SUM
In a database (Microsoft Access, Relational), is it possible to restrict access to a specific field in a table for a certain group?
So the group would have access to the table but not see one of the fields?
If not, is the only way to do this by seperating the data into another table and restricting it for this group?
You can not restrict access to a specific field.
However, you can create a query based off a table. And you can also set a table's "Visible" property to "No". This isn't foolproof; if the user knows how to change the properties of a table then they can change it back to "Visible".
There really is no 100% foolproof way to lock down an Access database entirely. However, you can make it awfully difficult by hiding the objects, hiding the database and bypassing the CTRL key (to avoid the old Shift/CTRL trick).
You can create different views for difference users | users group with only required columns that they should allow to access. Then grant permission for users/user groups on those views accordingly.
My question again to be more specific:
How can I modify data through a view and don't have to grant SELECT-Permissions on the table?
I am designing and developing a new database at the company i am working for.
The business rules say, that users are allowed to access specific rows in tables only.
So I use views to check the permissions of the user and return only those records, the user has access to.
So far so god.
But, I have to check the permissions also on INSERT and UPDATE and DELETE with INSTEAD-of-Triggers. Because the rows a User can SELECT may not be those, he can modify.
My problem is:
When I have an view and grant SELECT, INSERT, UPDATE and DELETE Permissions, it doesn't work. When I insert into this view, SQL Server wants INSERT-Permission at the base table. That wouldn't be a problem. But when I update or delete rows through the view, SQL Server wants SELECT and UPDATE/DELETE permissions granted on the base table.
I don't want to give SELECT-rights on the table.
Thanks
Chris
I'm thinking at:
1/ Restrict VIEW rows by adding in its definition a condition like this:
WHERE UserName = SUSER_SNAME()
or
WHERE UserName = CURRENT_USER()
or
2/ Using INSTEAD OF triggers on the involved view.
P.S. Indeed, CREATE VIEW WITH EXECUTE is not allowed. Thank you for your messages.
If I have three different user with different occupation (manager, salesman, accounting)
The main question is to how display right column to right person based on star schema and requirement below in SQL server?
The fact and dim are using regular table inside of data mart.
Background information:
The manager is authorized to see all column in factTransaction
The salesman is not allowed to see TaxAmount, TotalAmount and ProductBusinessKey.
The Accounting is note allowed to see Product Quantity, ProductPrice and GeographyFullname.
In windows, the they have their own user account.
The picture is take from the address (Design of a data warehouse with more than one fact tables)
SQL Server does have the ability to assign column permissions (http://msdn.microsoft.com/en-us/library/ms180341%28v=sql.105%29.aspx). You can set the specific permissions as you like, by treating each column as an object with its own security.
Managing column level security is likely to be cumbersome, because you have to remember to update the security every time the table changes and new users are added.
You consider a different approach. Define a separate view for each of the different groups. Only the manager would have access to the "manager" view; only the salesman (and the manager perhaps) would have access to salesman view and so on. Then build the application for each group based on those views.
Finally, managing multiple views might be a bit cumbersome. Instead, you can also have a table-valued function that wraps all the views into a single function. The function would check the permissions for each user and choose the appropriate data to return.
The advantage of user defined functions is that only the user who created the function needs to have access to the underlying tables. That is, the users only have permissions for the function; otherwise, they cannot see the underlying tables. The function would control what they can see.
If you had to design a database with paid users and trial users would you put them in the same table and differentiate between them with a field? Or would you put them in two separate tables?
Or would you do the best of both worlds and put them in the same table but create two views 1) PaidUsers and 2) TrialUsers
Thanks!
I just express some performance considerations in following opinions.
In single user query(ex. login check, or data retrieving for single user), there are not significant differences between these two strategies.
But if you need some statistic data, for example, one for paid users and another for trial users. And seperating to two tables may be a good idea.
Otherwise, if you need some statistic data whatever paid users or trial users, single table may be a good idea.
What if you need both of scenarios? Well, I think that would be a case which some common attributes exist between two kinds of users.
These common attributes should be put in one table, and dedicated attributes for particular users should be put in 'sub-table' inheriting from former table. Just as vonPetrushev said.
Since your paid users would probably be related to some additional data, but still have the same fieldset as non-paid, the correct way to do this is [is-a] approach:
User
id
username
password
fullname
...
Paiduser
user_id [fk->User::id]
account_id
.... [other addidional data]
EDIT: Now, the trial users will be all records in User that does not have entry in Paiduser. I'm assuming that Paiduser fieldset is a superset of the fieldset of a trial/normal user [User].
EDIT 2: To get a list of trial users, which are 'set difference' between User and Paiduser, the following sql should work:
select u.*
from (User as u
join Paiduser as p on u.id<>p.user_id)
The best solution may depend on database type. My experience is with MySQL and SQL Server. I've always put all users into a single table. Then differentiate as needed using fields. This could apply to paid/ unpaid or anything else. This solution meets 3NF standards and seems easier to me for maintenance etc. What reason would there be to use multiple tables?