Re: MySQL versus Postgres - Mailing list pgsql-general

On Mon, Aug 9, 2010 at 1:51 AM, Scott Frankel <frankel@circlesfx.com> wrote:
>
> On Aug 8, 2010, at 2:45 AM, Torsten Zühlsdorff wrote:
>
>> Scott Frankel schrieb:
>>>
>>> On Aug 6, 2010, at 6:13 AM, Torsten Zühlsdorff wrote:
>>>>
>>>> John Gage schrieb:
>>>>
>>>>> On reflection, I think what is needed is a handbook that features cut
>>>>> and paste code to do the things with Postgres that people do today with
>>>>> MySQL.
>>>>
>>>> Everyone of my trainees want such thing - for databases, for other
>>>> programming-languages etc. It's the worst thing you can give them. The< will
>>>> copy, they will paste and they will understand nothing. Learning is the way
>>>> to understanding, not copying.
>>>
>>> I couldn't disagree more.  Presenting working code (at least snippets)
>>> should continue to be a fundamental part of any documentation project.
>>
>> You missunderstand me. Working code is a fundamental part of any
>> documentation. But we talk about a handbook with code that works in
>> PostgreSQL and does the same thinks in MySQL.
>> This way the trainees won't learn how PostgreSQL works, the just learn the
>> different examples. Giving them training-problems and the PostgreSQL
>> handbook is out of my experience the best way. It tooks longer for them to
>> solve the problems, but in this way they are able to solve problems, which
>> are not related to the presented examples.
>
> I understand and appreciate your position.  Thanks for the clarification.
>
> While I believe that this thread has, for all intents and purposes, run its
> course (and I look forward to reading the documentation it informs), I'm
> going to go out on a limb and present an additional use-case that may be
> unpopular, or at least controversial.
>
> There are times when a documentation's audience is not interested in taking
> the subject matter to expert level.  (eg:  informed supervisory or
> vendor-client relationships, proof of concept development, hobbies, &c.).
>  For those cases, "a working understanding" is all that's strictly
> necessary.  Annotated, cookbook-style code reference is especially well
> suited for that mode of learning.
>
> Regards,
> Scott
>
>

I think it is important to have some examples in the documentation.
Some kind of balance between few examples and too many examples.
From what I have seen many users in this mailing list usually do
include some example code of the problem they have as an aid to
explaining their current situation. This seems to me quite useful. The
other day I asked for help in implementing  "DISTINCT ON" like
behaviour and was pointed correctly to the docs. The examples in
"DISTINCT ON" documentation quickly led me to understand the working
of this command. Sometime back I was learning about Window functions
(rank() and so on) where I found the examples very useful and I feel
it would have been a challenge for me to understand these concepts
without the use of examples.

There may be worry of "copy and paste" without proper understanding of
the code and concepts but this may be mitigated IMHO by fact that it
seems unlikely that when presented with a case to solve, simple "copy
and paste" of several commands (in the right sequence) will happen and
correctly solve the problem at hand without appreciation of what these
commands and statements do. Also more often or not the "copy and
paste" will only work on specific schema definitions and data used in
the example, therefore reconstruction (hence understanding) of these
commands is neccessary.



Allan.