| Author |
 Topic  |
|
RocketScientist
Official SQLTeam Chef
USA
85 Posts |
 Posted - 09/21/2001 : 16:01:55
|
A little of this, a little of that.
A good DBA should be able to do the following:
- Design databases to fit specific needs
- Critique database designs
- Build a server. From the point of "Taking it out of the box" to making sure it's ready for production.
- Design and implement effective backup policies
- Restore from a backup after those policies are not followed
- Write Transact-SQL scripts to move data from one schema to another
- Diagnose why those scripts are slow and fix them
- Diagnose and fix problems related to slow query performance
- Capacity Planning
- Writing scripts in Transact-SQL to fix bad data
- Writing scripts in some other language (Not VB) to massage data before it gets into SQL Server
- Import data from various flavors of text file
- Perform all of these tasks WITHOUT using Enterprise Manager or any silly little wizard.
- Understand why it's important to never use cursors
Why no VB? Because it's not the right tool for that job. If it's the only tool you've got, you need to get a bigger toolbox. Look into other languages, like Perl, C, csh, awk or python.
Why no Enterprise Manager? OK, here's a challenge. Try to do any of these things with enterprise manager over a modem link. Oops. Broken. EM sucks on slow links. That, and if you know how to do it with commands, then you understand how it works. Otherwise, it's all just smoke and mirrors.
Just my 2 cents.
chris.
|
 |
|
|
nr
SQLTeam MVY
United Kingdom
12543 Posts |
Posted - 09/21/2001 : 19:56:58
|
Why no VB...
Would disagree with this statement. You should be able to design the system so that the database does all the work efficiently and the preentation layer does just that - VB should be capable of doing whatever you need (as should ASP, C, or any of those others). If you think you need anything more you are probably in the realms of application programming rather than database (and I suspect think you need cursors  .
==========================================
Cursors are useful if you don't know sql.
You learn little from being right - benefit from being wrong.
Cold fizzy beer is wrong. |
|
|
|
carrey
Starting Member
United Kingdom
22 Posts |
Posted - 09/25/2001 : 10:21:45
|
quote:
Is that a denial?
Nope... it's a Daniel!
Sorry couldn't resist that..
|
|
|
|
RocketScientist
Official SQLTeam Chef
USA
85 Posts |
Posted - 09/25/2001 : 16:10:37
|
Why no VB? Simple. I didn't say it was for a UI or a presentation layer application, but to massage data. VB has too much overhead for that kind of operation (and is deficient in several other areas as well, such as regex handling).
VB is an excellent presentation layer language. DBA's, or at least the "Database Administration" part of the DBA's job, shouldn't involve writing presentation layer.
|
|
|
|
nr
SQLTeam MVY
United Kingdom
12543 Posts |
Posted - 09/25/2001 : 19:06:38
|
But it should include the database access layer - which is why I stick to VB based com layer interfaces.
Also VB is handy for giving users something to view and possibly update data. I always refuse to make it look pretty though.
==========================================
Cursors are useful if you don't know sql.
You learn little from being right - benefit from being wrong.
Cold fizzy beer is wrong. |
|
|
|
jhermiz
Flowing Fount of Yak Knowledge
USA
3564 Posts |
Posted - 07/31/2003 : 17:04:39
|
Had to jump in...
just read this thread from tara posting it in another thread.
First off why even argue :-p. If you're good at what you do and you're making it financially I see no reason that you would need to take any crummy ol test.
I'd agree with hiring someone with experience rather than someone who got a red sticker on their forehead. Whether you've cheated or not..that's not the case..it all comes down to personal experience.
Also on the note about VB..I think that was probably the worst post I'd ever seen. VB is not inefficent..the programmer is inefficient. I've used it throughout my years with excellent results for client server applications. Integration with other various MS Products is simple is easy and the inner workings of the ADO object through vb has been a breeze. The only thing bad about vb is its reporting capability...but from what I hear SQL is coming out with SQL Reports???
----------------------------
Jon H.
http://www.dbguy.com
|
|
|
|
robvolk
Most Valuable Yak
USA
15559 Posts |
Posted - 07/31/2003 : 18:53:25
|
Yes, it's called Reporting Services. It's another server app and it is .Net enabled, so you'll be able to do anything with/to it as far as expanding and programming goes.
The biggest problem with VB as far as databases are concerned is that people will use VB techniques to access their data. That's why the argument about "inefficient" was raised, and is essentially true. A lot of truly skilled VB programmers write horribly inefficient database code because they don't know (or want to learn) even basic SQL programming (easily recognizable because they resist writing stored procedures...anyone who doesn't want to write stored procedures is a lazy database programmer)
This is especially true in client server apps because they so often are bent around having a user interface, even when a particular feature doesn't require an interface. ADO does not help either, because it makes it TOO easy for programmers to just fire up a recordset and go MoveNext MoveNext MoveNext and UpdateBatch. No matter how fast that code might be, it is still far less efficient than a properly written stored procedure.
This isn't meant as criticism, it's just based on personal observation and experience with a lot of programmers. |
|
|
|
jhermiz
Flowing Fount of Yak Knowledge
USA
3564 Posts |
Posted - 07/31/2003 : 23:46:34
|
quote:
Originally posted by robvolk
Yes, it's called Reporting Services. It's another server app and it is .Net enabled, so you'll be able to do anything with/to it as far as expanding and programming goes.
The biggest problem with VB as far as databases are concerned is that people will use VB techniques to access their data. That's why the argument about "inefficient" was raised, and is essentially true. A lot of truly skilled VB programmers write horribly inefficient database code because they don't know (or want to learn) even basic SQL programming (easily recognizable because they resist writing stored procedures...anyone who doesn't want to write stored procedures is a lazy database programmer)
This is especially true in client server apps because they so often are bent around having a user interface, even when a particular feature doesn't require an interface. ADO does not help either, because it makes it TOO easy for programmers to just fire up a recordset and go MoveNext MoveNext MoveNext and UpdateBatch. No matter how fast that code might be, it is still far less efficient than a properly written stored procedure.
This isn't meant as criticism, it's just based on personal observation and experience with a lot of programmers.
Well I'm happy to say all of my data access layer sits on SQL Server.
I had posted earlier that I have over 340+ sprocs and Im still working on my application...it does a lot. I have at most 2 sql strings that are actually executed on the client side...which probably can both be sprocs..but that is nothing compared to most apps. I although am no expert at SQL cannot blame a lot of the vb programmers..many clients want a rough deadline rob so you can't expect some of the programmers to *cheat*. I just happen to know SQL and I had picked up a good book..so I did some practice run on SPROCS, Tables, and Views and found it quite simple. Sure I can't do the wacky stuff that some of you guys are coming up with, then again I dont spend as much time as some of you might be doing. I may know more C/C++ / Java / VB..but I lack some of the advanced features which make your db's a lot more nicer than mine :). Than again Im learning sevral things at once...so really its not all programmers. Its some..and even those some want to learn..time is money. Trust me we had a contractor who did just that..he used SQL Server just as a datawarehouse to house his tables. His code was all on the client side...so he was constantly making changes to SQL stmnts in the front end and redistributing...it was a nightmare.
Jon
|
|
|
|
rrb
SQLTeam Poet Laureate
Australia
1478 Posts |
Posted - 07/31/2003 : 23:58:16
|
hi everyone
I reckon it depends what sort of DBA you want to be. If you want to be like one of my guys who's responsible for making sure that the servers are up and running, doing the occasional data cleanse and otherwise sitting at your desk with your feet up downloading the latest cow-fu mpeg, then quite frankly YOU DON'T NEED TO KNOW SQUAT!!!!!!
(gee I hope he is isn't reading this)
Otherwise, there are a host of DBA's out there with no previous experience. Personally I don't want to be a DBA, any job-title with the word "Admin" in it has to be a bad choice....
Fact - everyone is eventually promoted to their level of incompetence
Subfact - everyone is actually promoted one level above their level of competence
Inference - never become competent at anything and you'll keep getting promoted
--
I hope that when I die someone will say of me "That guy sure owed me a lot of money" |
Edited by - rrb on 08/01/2003 00:00:10 |
|
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 08/01/2003 : 09:58:16
|
WOW!
What a history lesson....
It must have been fun "in the day"
Was that a mix of 6.5 /7.0 conversation going on?
My choice for a dba
WHERE Me <> 'Wake up at 3:00 am to fix stupid Server Ops mistake'
Brett
8-)
SELECT POST=NewId()
|
|
|
|
jhermiz
Flowing Fount of Yak Knowledge
USA
3564 Posts |
Posted - 08/01/2003 : 10:02:08
|
quote:
Originally posted by X002548
WOW!
What a history lesson....
It must have been fun "in the day"
Was that a mix of 6.5 /7.0 conversation going on?
My choice for a dba
WHERE Me <> 'Wake up at 3:00 am to fix stupid Server Ops mistake'
Brett
8-)
SELECT POST=NewId()
Brett you're such a nerd! |
|
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 08/01/2003 : 10:31:09
|
quote:
Brett you're such a nerd!
That's my day job...
But at Night....
Brett
8-)
SELECT POST=NewId()
|
|
|
|
tkizer
Almighty SQL Goddess
USA
35007 Posts |
Posted - 08/01/2003 : 13:44:24
|
quote:
Originally posted by X002548
My choice for a dba
WHERE Me <> 'Wake up at 3:00 am to fix stupid Server Ops mistake'
That was me last night and the night before. Although last night wasn't caused by anyone, an application service just got hosed (about 20 people get paged when problems arise and an operator can't fix it so even the DBAs get paged). The night before last was caused by me. I overlooked something during maintenance that we did Wednesday night at 10pm. We changed a database's name and I forgot to change the jobs that reference the name. So I got paged 3 times that night on job failures. I was going to ignore them until the morning although at the time I still didn't know what was causing the failures but I did know that it could wait until the morning. The third job was the DBCC CHECKDB job that failed. I almost crapped my pants when I saw that. Don't want to get a corrupted database in the middle of the night when all you can think about is going to sleep. So I dialed in and then realized that all 3 pages were due to the jobs not being modified to use the new database name. What an idiot!
Tara |
|
|
|
AjarnMark
SQL Slashing Gunting Master
USA
3246 Posts |
Posted - 08/01/2003 : 14:38:34
|
In regard to VB comments, let me paraphrase the argument... Many people (like me) coming from a background in VB or other non-SQL databases have a tendency to create solutions in an iterative fashion (cursors, readnext, update, etc.). Often in SQL databases a much better solution is set-based (update ... where ...). If you understand the right time to use each (and jhermiz, it sounds like you do) then great. But if you never learn the set-based approach, you can seriously hurt your database performance by using an iterative approach.
Now, Brett...quote:
Originally posted by X002548
WOW!
What a history lesson....
It must have been fun "in the day"
I cannot even begin to tell you some of the "fun" my cohorts and I had "back in the day". I'm sorry, but we've made a pact not to dredge up the ugly past. (Or maybe we're just in danile).
Ok, really, it's been a great 2 years for me, even if I have been MIA a lot in 2003.
------------------------------------------------------
The more you know, the more you know you don't know. |
|
|
|
tkizer
Almighty SQL Goddess
USA
35007 Posts |
Posted - 08/01/2003 : 15:16:25
|
quote:
Originally posted by AjarnMark
I cannot even begin to tell you some of the "fun" my cohorts and I had "back in the day". I'm sorry, but we've made a pact not to dredge up the ugly past. (Or maybe we're just in danile).
I wish I'd been around when he was around. I've gone back and read some of his ludicrous posts and it sure made my day.
Tara |
|
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 08/01/2003 : 15:36:28
|
Hey, I tell you what, I joined the firsty business day of this year...
Only fireworks I saw was from "he who shalt not be named"...
But I mean...I wish I knew about this place when I BAGIN my FUSCIA HEAD against the wall trying to figure out 6.5
Blue screen of death thy name be hell...
"Why are the transaction logs blowing out"
AAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
Brett
8-)
SELECT POST=NewId()
|
|
|
|
Arnold Fribble
Yak-finder General
United Kingdom
1961 Posts |
Posted - 08/02/2003 : 12:15:14
|
fuchsia, Brett. One of very few* words that start f-u-c.
* COUNT(DISTINCT word) WHERE word LIKE 'fuc%'
rather than COUNT(word) WHERE word LIKE 'fuc%', obviously.
|
Edited by - Arnold Fribble on 08/02/2003 12:19:31 |
|
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 08/04/2003 : 10:03:52
|
LOL...that's great...should have used a spell checker....
Say it with me slowly now...
FUC...HSIA
And
If you see Kay....tell her I love her...*
* Anson Funderberg reference...
Brett
8-)
SELECT POST=NewId()
|
Edited by - X002548 on 08/04/2003 10:04:58 |
|
|
|
shsmonteiro
Constraint Violating Yak Guru
Brazil
290 Posts |
Posted - 08/06/2003 : 23:45:32
|
Jesus, What is happening here? Shakpearean discussions on MCDBA (To be or not to be!! May Arnold RRB could write a poetry on this subject.)
I think one the biggest benefits of certification is the WOW! Your Boss, that does not know a bit of DB admin will tell you "WOW, congratulations! You've passed that 5 exams (He dont know that are 4, but who can blame him? He is a manager.) I could not pass it for myself (duh!!! Tell me what are the news)"
Your fellows would say: "God (that's not an expression, they really think you are the Almighty). How can I Shrink a Database? (It's a fact, all people seems to suffer a infatile regretion near to a certified. But, again, who can blame them, poor mortals? After all you are God - Dont deceive them)" Then, for these question you said, with voice of thousands thunders(remember: you are GOD!!!): "Drop and recreate it!!!" And what all those happy mortal people say? "GOD SAID. Let's do it." And for those sinners who have the courage to disagree with you, you can present your MCDBA/GOD cert, and use the reproach face. All other people will agree with you and that hansen illed will be banned to the desert.
NR? What are the cause for the UK addiction for get drunk? I remember that last year, while I was at IBM ITSO in Austin, there was a colleague from IBM-UK that was half-time half drunk and the other half completely drunk.
regards,
Sérgio Monteiro
Trust in no Oracle |
Edited by - shsmonteiro on 08/07/2003 00:27:28 |
|
|
|
rrb
SQLTeam Poet Laureate
Australia
1478 Posts |
Posted - 08/07/2003 : 00:20:15
|
quote:
Originally posted by shsmonteiro
Jesus, What is happening here? Shakpearean discussions on MCDBA (To be or not to be!! May Arnold could write a poetry on this subject.)
Arnold???!!!! Boy its hard to keep a reputation around here.
--
I hope that when I die someone will say of me "That guy sure owed me a lot of money" |
|
|
|
Topic |
|
Best steps to becoming a DBA.
