Re: [NOVICE] PostgreSQL Training

Quoting Bret Busby <bret(at)busby(dot)net>:

> On Fri, 12 Dec 2003, John Sidney-Woollett wrote:
>
> > Date: Fri, 12 Dec 2003 16:55:06 -0000 (GMT)
> > From: John Sidney-Woollett <johnsw(at)wardbrook(dot)com>
> > To: Chris Travers <chris(at)travelamericas(dot)com>
> > Cc: pgsql-general(at)postgresql(dot)org
> > Subject: Re: [GENERAL] [NOVICE] PostgreSQL Training
> >
> > Hi Chris
> >
> > In my experience, you typically find the following types of
> > database roles within organizations.
> >
> > The architect is the one who designs the database solution (hopefully
> > knowing the full capabilities and limitations of the database). SQL Users
> > are those that extract data from a predetermined database. The DBA's role
> > is to administer and tune the database to keep it running.
> >
> > Single | Departmental | Enterprise
> > User | Server | System
> > -----------------------------------------------------
> > Architect | Architect | Architect
> > SQL User | DBA |
> > DBA | |
> > -----------------------------------------------------
> > | SQL User | SQL User
> > -----------------------------------------------------
> > | | DBA
> >
> > I know that this is a *gross* generalisation, but most people will fall
> > into one or a combination of the three roles above (I suspect). What I
> > have called an architect, you have called a specialist. It goes without
> > saying that the architect role is a superset of the SQL User role.
> >
> >
>
> In the above model, is the database programmer, the SQL User as you have
> designated?
>
> For example, from my understanding, my wife, who works for a contractor,
> might design a database, she might, given the design, write the code to
> create and operate the database, or she might do both of those, or,
> given a database of which she has no previous knowledge, and for which
> no documentation exists, she may be required to figure it out; what it
> does and how it operates, and create bug fixes or modifications. The
> latter case has occurred, for example, in her informix history (from
> memory), when no documentation exists, when the database developer
> contractor has closed down, and, she is employed to fix or modify the
> software (or migrate it from one environment to another, as has
> happened more recently, from my understanding).
>
> My understanding of your model, is that when she designs a new
> database, she is an architect, needing to know the capabilities and
> limitations of the DBMS development environment, eg, PostgreSQL,
> Informix, etc, but, how is she classified in your model, in the other
> cases that I have mentioned?
>
> >From what I understand of the development area of my wife's employer, in
> one project, she may be the designer, in another, she may be the
> programmer, in another, she may be the tester, and, in another, she may
> be any combination of the three.
>
> Thus, perhaps, an "architect" needs to know what can be done, and a
> programmer needs to know (or to be able to work out) how to do it, which
> (I believe) needs more in depth knowledge than the "architect". The
> sales people also need some understanding of the capabilities, as, from
> what she has told me, sales people often try to sell (in good faith)
> unobtainable objectives (apart from unachievable deadlines).
>
> To know the capabilities and limitations for the role of the architect,
> is one thing, but, to know the syntax, and the extensions and
> workarounds required to achieve particular objectives, and, likewise, to
> interpret the code, to figure out what is going on and how it works, so
> as to be able to formulate and encode appropriate modifications, is
> another thing, and, is more than, for example a DBA or client's
> programmer, might involve.
>
> I think that perhaps your model may suit a company where the company
> develops its own software, and therefore does everything in-house, and
> does not contract out to other organisations, but, I think that the
> model may need varying, for contractor organisations, and for
> organisations that have a DBA, who may do some basic query development,
> and contracts out in-depth development/modifications. Just a thought...
>
> Thus, from what I have said, I suggest that courses/certifications,
> along similar lines to the MySQL certifications, would be useful, at
> least as starting points; a Core (or basic) Course/Certification, a
> DBA Course/Certification, and varying Developer Courses/Certifications
> (like the MySQL Professional Certification and the MySQL and PHP
> Certification), which could vary in level and in content.
>
> The Core Course/Certification could be a prerequisite for the others,
> and, could suffice for a basic SQL User as you have mentioned, and,
> could do for a starting PostgreSQL user/developer. Then the person could
> move on with the DBA stream, or, with the Developer stream.
>
> I do not have any idea of the degree of intellectual property involved,
> but, perhaps it could be wise, to use both the nature and the content
> (as in topics), of the MySQL courses/certifications, as starting points.
> I would think that MySQL should not have a problem with that, and, it is
> good to have a starting point model, even if only as a guide from whence
> to start.
>
> For that, people would need to put aside any aversions (they seem to
> exist) to MySQL, and, consider my proposition on its merits, and, the
> MySQL certifications models and pathways, and, the content of the MySQL
> certifications, on their merits, and, how they might be adapted, for use
> with PostgreSQL.
>
> And, I suggest that the MySQL certifications model, would certainly fit
> the model that you have indicated above, as well as the combinations
> that I have mentioned.
>
> --
> Bret Busby
> Armadale
> West Australia
> ..............
>
> "So once you do know what the question actually is,
> you'll know what the answer means."
> - Deep Thought,
> Chapter 28 of
> "The Hitchhiker's Guide to the Galaxy:
> A Trilogy In Four Parts",
> written by Douglas Adams,
> published by Pan Books, 1992
> ....................................................
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

In regards to the model, perhaps it would be wise to only define the roles
needed as opposed to the where those roles fit into the environment.

I agree, as a consultant, you might be tasked with providing any combination of
the DBA, SQL User (end user?), Architect. So the model do not completely apply
but the role are accurate. Why not just definite the roles since that is the
constant regardless of if its a person or group rendering the work. We could
have some diagrams of recommended organizational structure and work flow as a
guide. Seems like that might be helpful to people/organizations that are a less
experienced with a developement environment.

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com