Re: Thoughts on "Love Your Database" - Mailing list pgsql-general

From dandl
Subject Re: Thoughts on "Love Your Database"
Date
Msg-id 008201d1a5c8$56f9aaa0$04ecffe0$@andl.org
Whole thread Raw
In response to Thoughts on "Love Your Database"  (Guyren Howe <guyren@gmail.com>)
Responses Re: Thoughts on "Love Your Database"  (Geoff Winkless <pgsqladmin@geoff.dj>)
List pgsql-general
> owner@postgresql.org] On Behalf Of Guyren Howe

> 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?

I'm a strong believer in putting the business code next to the data, not the wrong side of the object-relational
divide.However, for many the challenge of writing and debugging SQL code is just too high! The SQL language on many
serverscan do everything but it's clunky, lacks modern language features, is hard to debug, often fragile and really
hardto get right. 

The only thing I can give you that might help is a cookbook on how to do it right:
http://thehelsinkideclaration.blogspot.com.au/2009/03/window-on-data-applications.html.

Meanwhile I'm busy replacing SQL with Andl, which can do everything SQL gets right and avoids most of the things it
getswrong. Look out for an implementation on Postgres real soon now. See
http://www.andl.org/2016/04/postgres-meet-andl/. 

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org







pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Function PostgreSQL 9.2
Next
From: "Charles Clavadetscher"
Date:
Subject: Re: Thoughts on "Love Your Database"