May 20, 2008 at 7:21 am
Kathi Kellenberger (5/19/2008)
You know, it really depends on the shop -- how job duties are divided. In small shops, sometimes the developer and DBA are the same person.The best practice would be for developers to ask the DBA to create the new objects and restrict the rights of the developers.
Thanks Kathi,
well, sure everything depends. I understand your point.
In my environment there is a change control system in place, developers create scripts, that are tested, including table creation. Then those scripts are passed to people who are not experienced DBA's, but put things into a test and then production environment. They do not have the full knowledge of a DBA.
Of course, when in doubts the developer comes and asks a DBA for help, but in my environment there is only one DBA who normally has a lot of his own work apart from DBA stuff to do and there are too many developers, so a DBA creating objects could be a small bottleneck to the development.
Also in a test environment I think it is better and quicker for the developer to create the objects, so that he knows how to do it, changes the structure anytime he wants to until a final version is ready, then creates the scripts and this way he also takes part and shares the responsibility for the consistency in the structure of the database. After all he is the one who works as the designer and builds the application.
Apart from that if only a DBA is to create objects, any mistakes are blamed only on a DBA and a developer will tend to say - "I did not create that table, it was the DBA".
Thanks again,
Richard
May 20, 2008 at 7:28 am
SQL ORACLE (5/19/2008)
It has nothing wrong for a user to access SQL Server using a domain account if the server is not a production server. You can set permission to his/her account according to your security policy.Normally, a user can only be a member of application role in a production server.
In either case, a user shoiuld not have SA. Otherwise, our DBAs will lose our jobs.
:hehe:
Well, you are right, access to SA should be restricted and that is what I am trying to do, because the application structure was created a long time ago by an external company and there was no DBA involved at that time who would say - NO ACCESS TO SA. Nobody really bothered about the security measures.
As to the access to a test system, I tend to keep my test and production systems the same, so no SA access in a test system too. Otherwise the test system becomes a mess and it doesn't make sense to maintain two systems in order to know, what should be in the test system that should not be in the production system - unless it's a new funtionality. Not to mention testing new development environments 🙂
Cheers,
Richard
May 20, 2008 at 7:39 am
For individual logins, strictly use windows authentication; never give shared logins. For code tracking, make use of some version control system. Also, see of schemas can be helpful for your environment.
May 20, 2008 at 8:02 am
Rajan John (5/20/2008)
For individual logins, strictly use windows authentication; never give shared logins. For code tracking, make use of some version control system. Also, see of schemas can be helpful for your environment.
Thanks, interesting SQL Server can do this.
We do have a change control system, howerever, this SQL Server application is not changed very often and it is done by an external company.
Yet I was considering implementing this in my Oracle databases.
Richard
July 23, 2010 at 11:38 am
Just wanted to say thank you for this well written article. As an accidental DBA I now understand Object Ownership much better than I did before.
Bob
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply