Обсуждение: career in SQL/Database administration
Can anyone reccomend a career path or maybe past experience on a good career path to becoming a DBA? I recently took a class on Intro to SQL at the local college and enjoyed it very much. I dont want to become a full-time PHP, SQL, ASP, Java,etc. programmer, though. My background is in Windows Networking and administration (AD and Exchange) and hardware troubleshooting. I assume as a DBA I would still be able to maintain the server hardware, systems, design, and networking layout, but still be able to create tables, modify data, and perform SQL maintainence all at the same time. I was told by my instructor many DBAs are past (or still current) UNIX System Administrators. I would not rule out switching to Unix/Linux as my platform of choice either, I've been an avid Linux hobbyist for over 5 years now. Sybase, Oracle, MySQL, MS-SQL preferred? Any further thoughts? Thanks!
Most of our DBA's (true DBA's) also need to know Unix\Linux\Windows &
perl\PHP\ASP to be able to interact the different needs of different
apps with the DB. Stick with Postgresql or Oracle (if you can afford
it).
Travis
-----Original Message-----
From: Bryant M [mailto:bry1255wm@netscape.net]
Sent: Monday, September 22, 2003 4:03 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] career in SQL/Database administration
Can anyone reccomend a career path or maybe past experience on a good
career path to becoming a DBA? I recently took a class on Intro to SQL
at the local college and enjoyed it very much. I dont want to become a
full-time PHP, SQL, ASP, Java,etc. programmer, though. My background is
in Windows Networking and administration (AD and Exchange) and hardware
troubleshooting. I assume as a DBA I would still be able to maintain
the server hardware, systems, design, and networking layout, but still
be able to create tables, modify data, and perform SQL maintainence all
at the same time. I was told by my instructor many DBAs are past (or
still current) UNIX System Administrators. I would not rule out
switching to Unix/Linux as my platform of choice either, I've been an
avid Linux hobbyist for over 5 years now. Sybase, Oracle, MySQL, MS-SQL
preferred? Any further thoughts?
Thanks!
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
I think most careers these days are shifting towards "package jobs" where one guy does everything. Jon On Mon, 22 Sep 2003, Bryant M wrote: > Can anyone reccomend a career path or maybe past experience on a good > career path to becoming a DBA? I recently took a class on Intro to SQL > at the local college and enjoyed it very much. I dont want to become a > full-time PHP, SQL, ASP, Java,etc. programmer, though. My background is > in Windows Networking and administration (AD and Exchange) and hardware > troubleshooting. I assume as a DBA I would still be able to maintain > the server hardware, systems, design, and networking layout, but still > be able to create tables, modify data, and perform SQL maintainence all > at the same time. I was told by my instructor many DBAs are past (or > still current) UNIX System Administrators. I would not rule out > switching to Unix/Linux as my platform of choice either, I've been an > avid Linux hobbyist for over 5 years now. Sybase, Oracle, MySQL, MS-SQL > preferred? Any further thoughts? > > Thanks! > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
> I think most careers these days are shifting towards "package jobs" > where one guy does everything. Either that, or you work for a consulting/contractor outfit, and the customer periodically cancels the contract in order to play hardball and "negotiate" for lower rates. Then you find yourself out of a job at least temporarily and periodically, so you never build up a vested retirement savings balance, or feel secure enough in your future to lay down solid roots in, and contribute to your community or give your children that important sense of stability and comfort as they are growing up... Too many companies fail to view any longer IT staff as a strategic asset. I'd think twice, given hindsight. ~bober > On Mon, 22 Sep 2003, Bryant M wrote: > >> Can anyone reccomend a career path or maybe past experience on a good >> career path to becoming a DBA? I recently took a class on Intro to
We dont' do hourly rates. We do it by the job. Therefore, the consumer doesn't have to think about how much they're paying us per hour. The just have to think about the benefits in relation to the cost. It also allows us to get better profit margins, because we can automate in innovative ways, and it doesn't cost us revenue. Jon On Wed, 24 Sep 2003 btober@seaworthysys.com wrote: > > > I think most careers these days are shifting towards "package jobs" > > where one guy does everything. > > Either that, or you work for a consulting/contractor outfit, and the > customer periodically cancels the contract in order to play hardball and > "negotiate" for lower rates. Then you find yourself out of a job at least > temporarily and periodically, so you never build up a vested retirement > savings balance, or feel secure enough in your future to lay down solid > roots in, and contribute to your community or give your children that > important sense of stability and comfort as they are growing up... Too > many companies fail to view any longer IT staff as a strategic asset. I'd > think twice, given hindsight. > > ~bober > > > On Mon, 22 Sep 2003, Bryant M wrote: > > > >> Can anyone reccomend a career path or maybe past experience on a good > >> career path to becoming a DBA? I recently took a class on Intro to > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend >
> We dont' do hourly rates. We do it by the job. Therefore, the consumer
> doesn't have to think about how much they're paying us per hour. The just
> have to think about the benefits in relation to the cost. It also allows
> us to get better profit margins, because we can automate in innovative
> ways, and it doesn't cost us revenue.
<rant>
Hehehe but this can pose problems. Lets say you've got a contract to
do foo by a week from today. You deliver on foo and do an amazing job
and get it to the customer two days early. The client should be ready
to bow down before you as lord -- this is how good the job is. So he
does it, right?
Well, in my experience it depends on the customer. If you get a
customer who knows IT, then yes, they bow down before you and hire you
again. But more often you get a customer who doesn't know IT, and
didn't realize exactly what he or she was ordering. So you've got a
client looking for revisions. But revisions mean substantially altering
the code base and losing lots of time (and $$$).
So what do you do? Sue them? Costs more then the client's contract is
worth. Tell the customer to pay more? They may walk away and the
deposit won't cover all costs. And if they say the contract wasn't
consummated (it wasn't what they wanted) see the section on lawsuits.
So now what, send them to collections? Maybe -- if you're big enough to
get a contract with a national collections agency. If not you're
basically consigned to bend over, and smile nicely as you get screwed
over with revisions.
</rant>
(Anybody with suggestions on what to do with people like this please
feel free to chime in. :-D)
-Dan
On Thu, 2003-09-25 at 11:27, Dan Anderson wrote: > > We dont' do hourly rates. We do it by the job. Therefore, the consumer > > doesn't have to think about how much they're paying us per hour. The just > > have to think about the benefits in relation to the cost. It also allows > > us to get better profit margins, because we can automate in innovative > > ways, and it doesn't cost us revenue. > > <rant> > Hehehe but this can pose problems. Lets say you've got a contract to > do foo by a week from today. You deliver on foo and do an amazing job > and get it to the customer two days early. The client should be ready > to bow down before you as lord -- this is how good the job is. So he > does it, right? > > Well, in my experience it depends on the customer. If you get a > customer who knows IT, then yes, they bow down before you and hire you > again. But more often you get a customer who doesn't know IT, and > didn't realize exactly what he or she was ordering. So you've got a > client looking for revisions. But revisions mean substantially altering > the code base and losing lots of time (and $$$). > > So what do you do? Sue them? Costs more then the client's contract is > worth. Tell the customer to pay more? They may walk away and the > deposit won't cover all costs. And if they say the contract wasn't > consummated (it wasn't what they wanted) see the section on lawsuits. > So now what, send them to collections? Maybe -- if you're big enough to > get a contract with a national collections agency. If not you're > basically consigned to bend over, and smile nicely as you get screwed > over with revisions. > > </rant> > > (Anybody with suggestions on what to do with people like this please > feel free to chime in. :-D) What you needs is a better lawyer, to write tighter contracts. -- ----------------------------------------------------------------- Ron Johnson, Jr. ron.l.johnson@cox.net Jefferson, LA USA Spit in one hand, and wish for peace in the other. Guess which is more effective...
> (Anybody with suggestions on what to do with people like this please > feel free to chime in. :-D) If you keep them involved in the development cycle, it's not usually a problem. A week of time isn't really enough. You're not giving them a chance to say "yes/no" that is/isn't what we want. Get multiple projects going at the same time, and give each of them a month or two. That way, you can design it and then give them time to review it and make suggestions. You can also give them a maximum number of divisions. If we tell the customer what kind of revisions can or can't be done, we're pretty good. If a client refuses to pay, that's a separate problem entirely. It sucks, but that's really a separate problem, don't you think? We've had pretty good luck with that, but we're in Oklahoma and if you screw someone over, everyone hears about it. Jon > > -Dan > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html >
Dan Anderson wrote: >>We dont' do hourly rates. We do it by the job. Therefore, the consumer >>doesn't have to think about how much they're paying us per hour. The just >>have to think about the benefits in relation to the cost. It also allows >>us to get better profit margins, because we can automate in innovative >>ways, and it doesn't cost us revenue. >> Are you serious??? How do you possibly make any money? Maybe I am just naive but here at CMD a flat rate quote is a minimum of 2.5x what we would normally charge JUST IN CASE the client (which will happen) decides to change direction midstream. > Well, in my experience it depends on the customer. If you get a >customer who knows IT, then yes, they bow down before you and hire you >again. But more often you get a customer who doesn't know IT, and >didn't realize exactly what he or she was ordering. So you've got a >client looking for revisions. But revisions mean substantially altering >the code base and losing lots of time (and $$$). > > Exactly what hourly is for :) > So what do you do? Sue them? Costs more then the client's contract is >worth. Tell the customer to pay more? They may walk away and the >deposit won't cover all costs. > That is why you don't deliver final product until the final check is recieved. We typically do a milestone approach so that by the time we deliver, if the customer decides they don't like it (for whatever reason) we are only out maybe 10%. > And if they say the contract wasn't >consummated (it wasn't what they wanted) see the section on lawsuits. >So now what, send them to collections? Maybe -- if you're big enough to >get a contract with a national collections agency. If not you're >basically consigned to bend over, and smile nicely as you get screwed >over with revisions. > Every contract... if written correctly values both parties. If one party signifcantly changes the scope of the contract and isn't willing to pay up.... stop work. Many, many clients will see the light once they have spent 20k with you and then you stop work because they won't pay for a milestone. Long story short... if you do it, have clearly defined milestones. If the project is more than 2500.00 bucks.... have a milestone for every 10 or 20%. Sincerley, Joshua Drake > ></rant> > >(Anybody with suggestions on what to do with people like this please >feel free to chime in. :-D) > >-Dan > > >---------------------------(end of broadcast)--------------------------- >TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com The most reliable support for the most reliable Open Source database.
> Are you serious??? How do you possibly make any money? Maybe > I am just naive but here at CMD a flat rate quote is a minimum of 2.5x > what we would normally charge JUST IN CASE the client (which will happen) > decides to change direction midstream. > We _plan_ for revisions. We even have a form to make it easier for the client. We have revisions programmed in to our timeline. We also have the scope clearly in our contract. If a revision is outside of scope, we change the contract. We're a full-service shop, so we can charge a lot of money for things that others can't. For example, we can charge $100/month for webhosting of a single small site, just because people don't want to be dealing with multiple companies. We don't offer our hosting services to the public, because they do cost so much. But it's worth it for people getting a full-service deal. In addition, we are a graphics-design-oriented shop. Let me tell you, graphics _sells_. In addition, once you sell a job to one client, you can usually find several other companies who want the same thing, and are willing to pay the same price. Just a couple of modifications and there you go. Establishing long-term relationships helps, too. For companies where you already know how they work, the time required to build something is trivially small - you already know their company, have their logos, and they like your work and know how to deal with you. Jon
> (Anybody with suggestions on what to do with people like this please > feel free to chime in. :-D) In situations where the client is not tech saavy or the scope is ambiguous, we bid high and ask for a 50% deposit. I think the best scenario is to get the client to pay for a detailed spec so they are clear on the deliverables beforehand and there are no disputes about what is in scope later on. In general though, we avoid fixed-rate jobs if possible (If you're paid hourly, then revisions and scope creep are good things.)