The DBA Code of Ethics
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/thedbac
-
One that I would add: The DBA has a duty to protect the data that we are guardians of. We have access to sensitive information, about our company's business, our clients, and even our coworkers. We need to protect it both from being accessed by unauthorized users, and use the utmost discretion in how *we* use, and interact with it. We have a duty to carry out our jobs with integrity, and not abuse the access to information that we often have.
-
Xanderno has right. The DBA Code of Ethics is good
-
In my opinion, special mention should be made about notifications when something goes wrong. This probably should be a part of Canon 3.
A DBA must do everything they can to ensure they receive a message when something goes wrong so that they can get on line ASAP and fix it and thus ensure minimal impact on users.
Also, I believe there should be mention of database backups somewhere. Canon 1 speaks a lot about protecting the integrity of the data. The DBA must protect the data from all forms of loss!
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems -
A DBA should seek to increase awareness of issues (such as security) to management and developers. You can lead a horse to water....etc.
A DBA should not seek to turn their work into a black art. Dispersal of best practices is a good thing).
A professional is someone who always gives their best even when they don't feel like it. A DBA must be professional.
A DBA should not leave logic bombs in ex-employers databases.
A DBA should not undermine another DBA.
A DBA should maintain enough documentation to ensure that loss of the DBA should not harm the business.
The law of the land takes precedence over the law of the CEO. This one is very difficult to live up to when you have a wife, kids and mortgage but if you work for an Enron, Worldcom, Equitable Life or an organistation that thinks you can deploy non-existent WMD in 45 minutes you need to think carefully about your ethics.
-
Another one came to mind.
A DBA should ensure the simplest code to do the job is being used. Sure, its nice to know VBScript and use it in DTS packages and sure that might help your job security if you are the only person who can understand what you did. However, if a simple T-SQL statement can do the same job as well or better then that is the route the DBA should take.
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems -
I'd like to add:
A DBA should make an effort to be as knowledgeable as possible in database fundamentals... Remember, without knowing why the (a) database is the way it is, you will never be able to determine in advance how it will behave.
--
Adam Machanic
whoisactive -
Good suggestions. I'll take them into account and produce an updated list in a few weeks.
One thing I want to point out is that I wanted this to be a general framework. If some technology changes, then the basic code by which we work shouldn't change. Therefore I didn't mention specific tasks that a DBA performs. Backups somewhat fit in here, though perhaps a general item about recoverability. I thought #3 covered this, but maybe not.
As far as knowledge goes, I hesitate to mandate knowing Codd's rules, normalcy rules, etc. I think #4 that you should be improving your databases is a good starting point.
Notifications is an interesting one. I'm thinking something about communications with other groups and users as something I left out.
Again great suggestions and keep them coming. I'm sure we can build a nice cross platform/cross RDBMS code of ethics that I hope most of you adhere to.
-
Steve, why would you hesitate to mandate knowing Codd's rules or the rules of normalization? Are you implying that someone can do the job of DBA well without knowing these rules? Granted most database professionals seem to know nothing about them (whether on purpose or just because they don't know the information exists, I'm not sure)... This is not a good state of affairs, which is why I suggested that you add it to the code of ethics for SQL DBMSs (not RDBMS! The SQL standard does not fully implement the relational model, and the word "relational" does not even appear in the standard.)
--
Adam Machanic
whoisactive -
Ahh, but a DBA could run a OLAP type db and not implement normalization. Or an object db where different rules apply. I tend to agree that a DBA needs to understand these rules, but they are a type of technology or set or rules that could change or not apply in some places. I wanted a list that applies very generally as a framework to those managing data as an administrator.
-
I don't think techie specifics should be included in a code of ethics for other than example reasons. When you look at normalization, codds rules, good code etc they don't seem to come across as part of an ethical guideline but rather a laundry list of gripes.
A code of ethics should be deliberately non-specific as it is meant to be a general guide rather than a checklist. It should take into account that all situations are somewhat different and boil all the specifics down into general principles. I think you've got a good start Steve.
What about something to do with learning outside of the db application. In my experience a DBA needs to understand networking, system administration, programming, application design and cultivate good people skills. Since our work includes all these areas that are traditionally broken into different teams in a large organization you have to be able to work with many different people without stepping on their toes.
How to boil that into a Canon? I dunno... Responsibility to continue your professional growth? Learn the environment that your application resides? Just a thought...
By the way, there is a canon you left out:
Canon 5 - The DBA should take all shots at his preferred DB platform personally.
All DBAs whether they be fans of SQL Server, Oracle, DB2, etc should sneer at the inneffectiveness of each other's chosen DB application.
"I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
(Memoirs of a geek) -
Let me get this straight, BrenBart:
You feel that a DBA shouldn't have to know DBMS foundations but should have to know networking, system administration, and other skills that are peripherally related?
Isn't that like saying that a carpenter shouldn't have to know about wood but should learn how to fix a leaky faucet?
Steve's Cannon 1: "The DBA must protect the integrity of data"
Learning the rules of normalization is ESSENTIAL to protecting the integrity of data! Without normalization there will be no data integrity. This has been proven in several different forums by Codd, Date, Pascal, and others. The only "gripes" in this laundry list are that database professionals seem to want to do their job without actually learning how to do it properly. Would you trust a carpenter who had never learned when it's proper to use a nail and when it's proper to use a screw?
--
Adam Machanic
whoisactive -
Well, actually amachanic you got it crooked. The laundry list I spoke of didn't actually include your post. It was about coding and backups. However, since you painted a big bullseye on yourself...
I never said that a DBA shouldn't have to know DBMS foundations, BCNF or anything else. I simply said that they aren't appropriate for a code of ethics. After all, a code of ethics is a set of principals to guide ones behavior not a set of laws to be mandated.
While BCNF is the foundation of relational databases Codd himself had to admit the fact that based on his rules there is no fully relational database system available. This means that you can't hold up normalization as the holy grail to a DBA. It's important but only really applies to a DBA who's primary responsibility is developing databases.
My point is that a DBA's responsibility is to his employer's interests. While I've only been a DBA professionally for seven years now I have yet to find a software vendor who will allow their time and money to be bothered with strict adherence to BCNF. On the other side of the street as a DBA for vendor clients, we rarely have any say in the database design of a product brought into our environment. When there are problems in the database design you have to be able to provide proof that this design is causing the issue.
It's all about priorities. A really tight, efficient database design is great and if more database designers paid attention to normalization we wouldn't have to clean up so many messes. However, since a large portion of the DBAs responsibilities extend beyond database development it is essential that you know as much as possible about how your system interacts with it's environment. You can't just say "It's not the database design so it's not my problem."
As a sidenote, being a former carpenter I find your analogy rather interesting. In fact, it sort of proves my point. The reasons behind where you use a nail and where you use a screw is based on time, expense, effort and application. Screws generally last longer but are more expensive and take greater effort to install. Both methods are shortcuts on the wooden peg method which usually lasts longer. In all three cases you are trying to hold two or more pieces of material together. You have to look at what you are building, maintaining or fixing with respect to how it is used, where it is located and why you are doing the work. Many of these factors are outside the boundries of simply knowing how to build. You can be a carpenter without knowing anything about electrical, roofing, plumbing, heating and ventilation but I wouldn't want to hire you.
"I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
(Memoirs of a geek) -
<<< I never said that a DBA shouldn't have to know DBMS foundations, BCNF or anything else. I simply said that they aren't appropriate for a code of ethics. After all, a code of ethics is a set of principals to guide ones behavior not a set of laws to be mandated. >>>
I would tend to agree with BrenBart on this. Do we want to assume that relational db's are the only type of database to be considered, now and forever? Yes, we do have to know the five forms of normalcy, when they apply, when they don't, and when performance has to take precedence. I work as a db for governmental financial accountants and they have their accountants and auditors codes of ethics but their actual accounting rules are always changing, but not as fast as technology.
Ross
-
PhoenixDBA:
My original quote: "A DBA should make an effort to be as knowledgeable as possible in database fundamentals... "
Note I did not say "relational database fundamentals." I merely said "database fundamentals."
How is it that you feel anyone can do a good job at ANYTHING without knowing the basics in that field? A lot of database professionals I talk to can't even tell me the difference between a database and a DBMS. Or the difference between a data model and a schema. Or anything else, for that matter, that's not product-specific (difference between SELECT syntax in Oracle and SQL Server? No problem!)
Technology changes, but basic mathematical and logical fundametals CANNOT change. A database professional should know database basics in order to do his or her job properly.
--
Adam Machanic
whoisactive
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply