Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Career questions: databases

Re: Career questions: databases

From: dreamznatcher <tashfeenmahmud_at_gmail.com>
Date: Sat, 30 Jun 2007 16:15:29 -0700
Message-ID: <1183245329.522411.176300@i13g2000prf.googlegroups.com>


On Jul 1, 3:56 am, hpuxrac <johnbhur..._at_sbcglobal.net> wrote:
> On Jun 30, 4:39 pm, dreamznatcher <tashfeenmah..._at_gmail.com> wrote:
>
> > > > Hello,
> > > > I'm considering a career switch to a more database-related job, but
> > > > need help on a few questions and issues. I'm a Computer Engineering
> > > > graduate and have always felt most comfortable creating database-
> > > > driven applications, preferably for web portals.
>
> > > > [My questions:]
> > > > 1. What are the most viable career options for me out there? What
> > > > profile do I fit in?
>
> In the United States where I am, there appears to be some fairly
> strong demand for computer professionals with strong oracle skills.
> With the success that oracle is enjoying in the commercial marketplace
> people that can integrate oracle authored applications as well as
> custom solutions based on oracle database technology appear to have a
> good chance for sucess in the long run.
>
> > > > 2. What is the current job market/salary situation for database
> > > > professionals? With my current skills, what kind of job might I end up
> > > > with?
>
> Varies by how much work experience you have. The oracle dba
> marketplace is typically one that is not easy for people to break into
> without relevant work experience but the overall demand factor may be
> changing that.
>
> > > > 3. What are the stuff I should focus/learn to advance my skills
> > > > optimally?
>
> Real database design experience which integrates theoretical knowledge
> with practical solutions. Lots of time spent doing and working
> through ERD based projects.
>
> As unfortunate as it sounds, often you learn the most from mistakes
> that you make during the design process. Many of us have been around
> long enough and made enough mistakes ( regrettably ) that experience
> starts sounding alarms when the design has problems.
>
> Many of us make the same mistake more than once. Hopefully by the
> time you get around to the third time you may still be headed toward a
> bad decision but at least you may be getting nervous about it.road to
> disaster.
>
> snip
>
> > Hello everyone,
> > (Mr Morgan and rkc on comp.databases.ms-access:)
> > I've mailed you about this a little while ago (I actually wanted to
> > post it but had clicked on "Reply to author"), but don't want to
> > bother you further on this and through your mailbox, so I'm posting
> > this here again.
>
> > Yes, I am extremely sorry for appearing so naive and having such ill
> > taste, but I tried to express my situation as honestly as possible and
> > unfortunately that's what I came up with. I do agree with you on the
> > use of the word "proficient" -- one truly cannot be that skilled in
> > anything these days. All I wanted to say was that I know a bit of
> > those stuff, enough to get my work done, and not in standards
> > considerably horrible by any means.
>
> Umm proficiency is something that is gained over the years and by
> years of relevant experience not months.
>
> I don't recall anyone calling you horrible.
>
>
>
> > I don't claim that I'm bullet-proof in any of the scripting languages
> > or web stuff I've mentioned. But I do know that I can conceptualize
> > (including front-end design and dealing with constraints and integrity
> > issues) complex database-shouldered systems
>
> Conceptualizing designs is a good starting point. But it is easy to
> start talking and get excited without doing enough homework in any
> given area.
>
> ERD is what it is all about for relational systems. The entities, the
> attributes, the relationships between entities, and the type of
> relationships ( one to one, many to one, many to many ). Subtyping
> and supertyping.
>
> Complex systems have a whole bunch of entities. ERP systems are
> complex. CRM systems are moderately complicated. It's not the same
> thing.
>
>
>
> > (here's one for you: I
> > often fiddle with the idea of creating a singular application that can
> > integrate and manage all the possible tasks, divisions and departments
> > of an organization on the scale of the EU or UN in their totality)
> > pretty fast (fast, e.g. I was working on this project that would
> > handle $30M in the national reserve, an application that would reduce
> > stagnancy of stored cash in the banking network by branching out to
> > web portals that would circulate revenue. The idea is far more
> > complicated than can be stated in a few lines, and was slated to be
> > reviewed by the Finance Ministry. If anyone of you follow the current
> > political scenario of Bangladesh, you'd know drastic political changes
> > are going about here, and the project got lost amidst more realistic
> > problems in the backdrop of a country where computer literacy accounts
> > for less than one percent. Getting back to the time factor, the whole
> > thing only took me 2 days to chalk out, including drafting the
> > interfaces.) I'm no expert, but whenever I took a database related
> > course in my university, literally half of the CSC department would
> > crash in to watch the demonstrations. Teachers and students would
> > repeatedly inquire about my project throughout the semester, and the
> > whole faculty has repeatedly asked me to get serious in this business.
> > These are the kind of things that have got me inspired and pushed the
> > humble, stupid likes of me far enough to be seeking for your advice.
>
> Not trying to be pessimistic but what do you mean by "chalk out". Two
> days doesn't sound like near enough time to even get close to thinking
> you have a complete ERD of the relevant entities involved.
>
> You also have a complete design of relevant interfaces in 2 days?
>
> To me at least, in 2 days you might have done some serious thinking
> about this area and just started to realize how complicated it might
> be.
>
> That's a whole lot different from having a good database design as
> well as a set of business requirements.
>
>
>
> > As I've mentioned, I come from Bangladesh. Lots of problems abound in
> > the tech domain here: lack of books and information, near-zero
> > advanced expertise in specialized fields, sluggish bandwidth, fund
> > crises, lack of support from the government, a dearth of firsts.
> > Therefore, questions I might be asking might actually appear more
> > stupid in your context than ours.
>
> > By posting this post (the original one and this), I didn't and don't
> > intend to appear smart, or show off (I very definitely know how
> > illiterate I am in this area), or pull anyone's leg, etc. I started it
> > because I am just an average mid-career guy who feels he has a knack
> > for something and would like to pursue it, despite all odds if
> > necessary, and just want to know what the odds are in advance and from
> > people who are most certainly more knowledgable than I am.
>
> Start with the basic texts in the database design world. You need to
> vary between ones that are application based and include sample
> designs and the theoretical ones.
>
> Do you know that the theoretical ones are? I can get to work on
> monday and pick some of the best titles and books but if you take a
> look at amazon and search on "database design" you can probably get a
> good idea.
>
> > No offence, and thank you to everyone in all earnest.
> > dzn-
>
> Best of luck.

Dear hpuxrac:
Thanks, first off, for such a detailed and helpful response. That should be the end of this string, but I feel I should clarify a few things.

> Not trying to be pessimistic but what do you mean by "chalk out". Two
> days doesn't sound like near enough time to even get close to thinking
> you have a complete ERD of the relevant entities involved.

> You also have a complete design of relevant interfaces in 2 days?

> To me at least, in 2 days you might have done some serious thinking
> about this area and just started to realize how complicated it might
> be.

By "chalk out"/conceptualize I precisely meant doing ERDs. Yes, I did it; it was very big -- it took me around eight cartridge-size papers taped together and got my back strained. But the whole thing didn't take me more than 2 working days (~20 hrs at most) and I enjoyed it thoroughly. And, I drafted the interface -- like this page/frame will look like this and have these objects/forms and accept these kind of entries, yadda yadda yadda.

> That's a whole lot different from having a good database design as
> well as a set of business requirements.

I've done ERP, and maintained appropriate design standards. I don't know what's a CRP.

And at this point, could I afford a further question? : Is drawing ERDs and chalking out how a database application will work (on paper) such a big deal? If it is, what do you call the guy who does it.. the database architect or something?

> I don't recall anyone calling you horrible.

Obviously. But then you get impressions like these:

   >> Lists like this create an immediate negative impression except in

   >> HR departments staffed by former shoe salesmen

and not to mention pegs getting hammered into your head, and into where-not of the issue, when you're only trying to get serious. Not nice, and definitely gives you the impression you're off-market. Sorry if this is only me getting affected.

Lastly, the same thing I started off with: thanks. Received on Sat Jun 30 2007 - 18:15:29 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US