Re: Thoughts on "Love Your Database"

On 4 May 2016 at 06:11, Guyren Howe <guyren(at)gmail(dot)com> wrote:

> I've long been frustrated with how most web developers I meet have no idea
> how to use an SQL database properly. I think I'm going to write a book
> called Love Your Database, aimed at web developers, that explains how to
> make their apps better by leveraging the power of SQL in general, and
> Postgres in particular.
>
> I'm thinking of a section on features of SQL most folks don't know about
> (CTEs are *way* to hell at the top of that list, but also EXCEPT/INTERSECT
> and window functions), but much of the book would be about how to do things
> server side. Benchmarks showing how much faster this can be, but mostly
> techniques — stored procedures/triggers/rules, views.
>
> I asked a colleague about the advice I often hear stated but seldom
> justified, that one shouldn't put business rules in the database. He
> offered that server-side code can be hard to debug.
>
> I'm sure many here would love to see such a book published, maybe some
> talks on the topic given.
>
>
> What might I cover that I haven't mentioned? What are the usual objections
> to server-side code and how can they be met? When *are* they justified and
> what should the criteria be to put code in Postgres? Any other thoughts?
> Any other websites or books on the topic I might consult?
>
> TIA
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Hi,
at my previous jobs I was working with many programmers, and almost none of
them understood SQL. The problem was even deeper. They didn't want to learn
it. When I was working among java programmers, I noticed that they hated
SQL, but there was no problem with learning HQL, which in fact is quite
similar. I really have no idea why it is like that.

I was thinking about such a book too, I have even started writing that, but
the whole set of ideas was always either too large or was a copy of what
can be found in other, general programming books. And if programmers don't
want to read the other books, and learn basics of SQL from there, then the
whole idea seemed useless to me. Of course the other reason of not writing
the book was lack of time, as writing a good book requires enormous amount
of work.

On the other hand I think that the huge problem with programmers and SQL is
changing the mindset. A standard programmer usually has a problem with
thinking in sets. Instead she usually thinks in terms of loops, and objects.

When I was giving talks about what not to do in databases, people were
either not interested or everything was a surprise for them, even for quite
experienced programmers. However after such a talk, or a training, people
were still not interested in knowing more, but they were happily learning
about programming.

I think it would be great to have a book like that, and I think it should
not be only about Postgres. But here is the problem I had with this
concept: to describe all the things to a normal programmer, assuming she
will be interested, it will need to be quite a huge and complicated book.

Or maybe this book should be about something else, start from an ORM, and
show how to translate it to much better SQL, as ORMs are the things
programmers usually understand, and they really don't bother that using
them can be a bad idea.

--
regards Szymon Lipiński