I like to put all intelligence in the database, instead of the middle language (PHP, Python, Node, whatever). People argue about whether to put all your intelli

I like to put all intelligence in the database, instead of the middle language (PHP, Python, Node, whatever). People argue about whether to put all your intelligence and business logic in your database, and I think you should google it and read about it for a long time. I say the moment you make a column unique or add a foreign key, you have already begun. What most people do is have part in their database and part in their middle scripts. And it's not by design so much as by how well they knew SQL at the time. People typically learn the middle language first, be it Python or PHP or what have you. They know how to write the business logic in that language, and they only have so much time and energy, and I don't blame them. Learning SQL in general and Postgres in particular takes a long time, but the more I've learned, the more I move. Now that doesn't mean PL/PGSQL, because I like to use the simplest tool that does the job. From simplest to most complex, you can: 1. Put it in the table definition, things like: data type, null or not null, unique, foreign key, and check constraints: create table orders ( id serial PRIMARY KEY, item int NOT NULL REFERENCES items, qty int NOT NULL CHECK (qty > 0), ... ); 2. Put it in a database view definition. If your SQL is getting long and complex, save it to a view, so your application doesn't have a tower of SQL in its source code. Views can also warn you when you're changing tables in a way that will break something ("You can't drop this column because this view depends on it, you can't change this column's type to that because a view depends on it, etc."). Of course you can drop and recreate the view after changing the table, but at least it warns you. Other times, like if you rename a column, I think the view updates automatically. None of this would happen automatically if the SQL is hardcoded in your Python script. 3. Put it in an SQL function (SQL, not PL/PGSQL). 4. Put it in a PL/PGSQL function. That's the order I take, from smallest hammer to largest.