Re: [NOVICE] PostgreSQL Training - Mailing list pgsql-general

On Fri, 12 Dec 2003, John Sidney-Woollett wrote:

> Date: Fri, 12 Dec 2003 16:55:06 -0000 (GMT)
> From: John Sidney-Woollett <johnsw@wardbrook.com>
> To: Chris Travers <chris@travelamericas.com>
> Cc: pgsql-general@postgresql.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
....................................................