What's the requirement? Where's the boundary? Is there any?
6 Answers
Start with the DB you have to administer. Learn it inside and out. Then, decide what you want to learn. Applying the same principles to a new system will not be as hard as trying to learn several at the same time.
Ask yourself, "Why do I want to learn this?"
There are many other types of database models beyond relational. chouchdb is a great example of a hash-table style database. Look around, figure out what will
- Pay the bills
- Make you happy
or
- Make you happy
- Pay the bills
There will always be someone who knows more than you. Don't try to make yourself strong in all fields, you will be equally weak in all of them. Build to your strengths, mitgate your weakness.
-
1
-
3
I think there is some basic knowledge all DBAs should have. This includes skills and activities like
- database implementation and design
- performance monitoring and tuning
- availability, backup and recovery
- organizational skills (planning / paying attentions to details)
- and last, but not least: how to work with developers and network admins
You should also have fundamental knowledge of IT security and be willing to be, like software developers, a lifelong learner.
These concepts can be applied to any database product out there. If you have experience in two or three different vendor's products, you'll learn the others without any problem.
No, a DB admin does not need to know all the DB systems out there.
Learn the fundamentals you can apply anywhere like splattne mentions. For vendor specific learning, I would recommend Oracle and MSSQL as they are both well established in large enterprise. At the end of the day you will need to know some DBs well to get a decent job.
I agree with the others for the most part. Knowledge is power and the more you know, arguably the better you will be able to do your job. I specialize in SQL Server, but am somewhat literate in other big ones like MySQL and Oracle which has helped me out quite a few times. Some specific benefits for knowing multiple DBMS's (other other system platforms for that matter) include:
- Interoperability. When you need to provide an interface between two different systems it's exceedingly beneficial to have at least a working knowledge of both.
- Credibility. I've found it handy a number of times to debunk what someone's telling me of their system when they assume I don't know anything about it because I work primarily with "the other" system
- Architecture. Just because you know one system doesn't mean it's the best fit for all jobs.
I don't think that there is a real requirement outside of an environment's specific job requirements. The boundary is up to you as the admin / dba / developer. How much time are you willing to put into learning X number of different systems? Where do you draw your own line? Suggestions can be made, but you're the only one that can draw the clear line.
With specific regards to a (relational) DBMS, they have some common denominators (base SQL, basic db objects, etc) that will give you a great head start in "knowing the systems". Learn the basics and then learn where each system begins to differ in its support for them, then (or at the same time) learn the more advanced features of each system.
-
+1 for "Just because you know one system doesn't mean it's the best fit for all jobs" - the number of times I've seen people fall victim to that one is staggering. Jun 15, 2009 at 17:50
Enough? Nothing is enough in IT, but there is a large difference in having a fair knowledge and being an expert.
If I would hire a database admin I'd require him/her to be very good with the databases we use, but also have a knowledge about what other types of databases there is out there to stay current.
How do you really know your database is delivering the best value to your employer unless you have at least a basic understanding of the alternatives?
That doesn't mean you should know the competition as well as your main platform, but you should probably have a basic understanding of the performance characteristics and general feature set of each relative to your main platform. If your boss asks you why you're using platform A rather than platform B, you should be able to tell him.
Taking a SQL Server shop as an example, this doesn't mean you should use MySQL or Oracle for a specific application in your shop when everything else runs on SQL Server, even if that other database may be more suited to that application. Your expertise will be in SQL Server, and so you may not be able to efficiently manage the other database flavor. You're likely to do just as well or better keeping your environment homogeneous.
It does mean that you should know enough to be aware of when the business as a whole is moving in a direction that might perhaps favor a different database platform from what you use currently.