Here is what I am trying to accomplish with SQL Server, is this possible, and if so, what is the best approach?
Move all tables from the dbo schema, or change permissions to view only for anything but a stored procedure
Only stored procedures will have access to write and update the tables within the schema, dbo or a private schema.
I am doing this because I am the only dev in my company who has any type of database management experience; the other devs just edit tables live, create and update willy-nilly. I am coming in as a senior and am trying to prevent direct table create/update/delete; I believe all creates and updates should be managed through a stored procedure to help maintain data integrity and ensure proper time stamps are updated.
Is doing something like this possible? If so, what is the best approach?
Related
I am wondering what the best way (or any way) to manage a database schema. I have a sql file with a bunch of statements like CREATE TABLE Users { id SERIAL PRIMARY KEY ....}; which represents the schema for my database.
I have postgres installed on my dev machine however am having trouble syncing the changes I make to the schema with the local database. Currently I just run drop the entire database and run the schema file on the database.
I figure there has to be a better way I don't know about. I will also need to be able to set a database up for production when the project becomes more stabilized and obviously dropping a table in production wont work.
Suggestions?
Is there a way to find out which tables and stored procedures a user has accessed? Note that this is what the user has actually accessed and not what they can access.
For tables, is it also possible to know whether the access was read or write?
I would like this information to determine which database privileges can be removed for this user.
It is possible, but not for the past. On SQL Server 2014, you can setup specific monitoring tasks (called "audititing"), so that from now on you can collect the access data you want.
We have a SQL server that we are using for our data warehouse.
We want to give a department the ability to update the data when they want (and not just on schedule).
Was is the best way to do this? We have a SP that we are thinking of calling from a batch script, but is there a more elegant way?
The data will eventually go into Palo Jedox for BI.
I do this sort of thing by writing a ColdFusion web page that the user can run. It could also be done with .net, php, java, etc.
Do not give users the ability to change the tables directly.
Instead, create one or more stored procedures to do the updates/inserts/deletes that you want to do. If it is one record, you can just pass in the values as arguments. If it is a bunch of records, you need a mechanism to transfer larger data into the database -- either reading from a text file or putting it into a table in the database some way.
Be sure the stored procedure has the same owner as the underlying tables. Using owner chaining, the stored procedure will be able to make changes to the tables. At no time can a user make a change to the data directly, only through the stored procedure.
Then, log, log, log everything that gets done. You want to know every time this stored procedure is called to change the data.
Is there a way to make a schema diagram from an SQL Server database using the stored procedures of this database?
I don't mind if I must use an external software.
You could try playing around with CodeSmith Generator. It's SchemaExplorer Schema Discovery API allows you to programmatically access database elements for a given database and do something creative with it. However, it will still be logically hard to reverse-engineer a schema/diagram this way.
You can build a SQLCLR procedure which uses the Scripter Class from the SMO library.
update: more info on the question reveals the idea is to generate a table schema with dependencies based on the content of the stored procedures.
The approach would be to generate the table structure from the information_schema views and then parse the contents of the syscomments table to figure out the relations. This will always be approximate as it is very hard to establish the one-to-many relationships purely from the SQL Statements. I think you can make a guess based on the field which is referenced more.
If you can't see the tables then you can not generate the schema.
That is, you can't if you have permissions on stored procedures only.
At least two reasons:
the stored proc may JOIN and use several tables
you can't see constraints, indexes, keys etc even if you had table names
Basically, you can only:
see what you have permissions on in SSMS etc
see the internals if you have VEIW DEFINITION rights
Edit, after clarification
There is no way to script implied aspects (such as missing foreign keys) of the schema from code
I want to give access to certain data, in various databases on a single sql instance, to our parent company. They don't want a web service but instead want a stored procedure, which would compile data from different data sources and return a record set.
There is a trust between our two domains so essentially they are on our domain and I will just give the required permissions to sql objects (stored procedures)
I plan to create an 'integration' database which would have the required stored procedures.
While the integration database will have no tables itself, at least for now, I do want to lock the database down so that there are no holes such as the parent company being able to create tables on database or affect permissions etc.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicity give permissions to.
As a sql DBA I make a good .net programmer ie from what I understand it will require the user of commands such as GRANT EXECUTE ON [procedure] TO [user] to grant permissions on selected stored procedures, but beyond this I am not sure of a clear strategy to achieve what I need.
I want to make sure I don't leave holes in the security.
If anyone can advise the steps I need to take, ie what commands I need to run to achieve what I want, or point me to a good article I would appreciate it.
I have already run the command REVOKE CONNECT FROM GUEST on the database.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicitly give permissions to.
Create a role specifically for the users from the parent company
Only grant EXECUTE to the role for the specific store procedure(s)
Grant the role the db_datareader role -- that will make sure they can't create tables, etc.