I think one of the key questions is when to put logic in the database (and this is controversial so it may be worth covering from a few angles). In general my view is:
1. Data logic belongs in the database
2. Logic you can't roll back belongs somewhere else
3. A lot of stuff could go either place.
Another thing I would recommend is looking at SQL in a way that is similar to map(), reduce(), and filter() (using python terms but you can find similar in other languages).
Additionally some functional programming theory can go a long way in both understanding database normalization and putting logic in the database.
On Wed, May 4, 2016 at 6:11 AM, Guyren Howe <guyren@gmail.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?
