On Fri, Dec 30, 2016 at 2:50 AM, Pavel Stehule <pavel.stehule@xxxxxxxxx> wrote:
> would like to find a book or other resource
about SQL server-side programming (stored procedures etc) best practices
in general and for Postgres in particular.2016-12-30 8:04 GMT+01:00 Guyren Howe <guyren@xxxxxxxxx>:
> On Dec 29, 2016, at 23:01 , Regina Obe <lr@xxxxxxxx> wrote:
>
>
>> As an aside from my last question about my LYDB effort:
>
>> https://medium.com/@gisborne/love-your-database-lydb-23c69f4 80a1d#.4jngp2rcb
>
>> I would like to find a book or other resource about SQL server-side programming (stored procedures etc) best practices in general and for Postgres in particular.
>
> Shameless plug
>
> Have you checked out our book? The 2nd edition covered PostgreSQL 9.2 - 9.4.
> http://shop.oreilly.com/product/0636920052715.do
>
> We are working on the 3rd edition which is a bit fatter (probably will be about 50 pages fatter when we are done) than the 2nd edition.
>
> http://shop.oreilly.com/product/0636920052715.do
>
> The 3rd focuses on PostgreSQL 9.5-9.6 (and is in prerelease sale at moment). By the time of release, we'll probably have some PostgreSQL 10 content in there as well.
>
> It covers fancy SQL constructs and data types (both ANSI ones and ones unique to PostgreSQL), general administration, and writing stored functions with SQL, PLPGSQL and PL/V8.
>
> In the 3rd we are adding an additional PL/V8 example how to build a window function in PL/V8 (aka PL/_javascript_)
I’m sure the book is great. But it looks like much of the material I can find about Postgres: how to write a function, how to write a query, etc.
What I’m more looking for is “System Design with Postgres”: *when* to write a function, *when* to use a stored procedure over a client-side function.Lot of Oracle's books related to this topic is valid for PostgreSQL too. The design of stored procedures in PostgreSQL is conceptually similar to Oracle.The theme "stored procedures" is strongly controversial - from "stored procedures are evil" to "do all in procedures".I like the strategy - what you can do easy in database, do it there - the client should to get a results. But don't do communication server from database. PostgreSQL is ACID, stored procedures are ACID. Outer world is not ACID - and interface ACID/NOACID is better to implement outside database.RegardsPavel
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I'll start off with Enumerated types are evil. You are much better off with Foriegn Key Constraints.
That being said, there are four excellent books that I always recommend to my clients:
PostgreSQL Development Essentials:
https://www.amazon.com/
PostgreSQL 9 Administration Cookbook
https://www.packtpub.com/big-
PostgreSQL Server Programming
https://www.packtpub.com/big-
PostgreSQL 9.0 High Performance
https://www.packtpub.com/big-
In addition, I've attached my own controversial PostgreSQL Developer Best Practices
--
Melvin Davidson
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.![]()
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
Attachment:
PostgreSQL Developer Best Practices.doc
Description: MS-Word document
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
