3 ms·
Mine too! Having logic embedded into SQL functions seems to be an anti-pattern to me (it's harder to maintain and harder to do release management). While it's g
by devy 9y ago
Mine too! Having logic embedded into SQL functions seems to be an anti-pattern to me (it's harder to maintain and harder to do release management). While it's great that Postgres can do this (btw, I love Postgres), I suspect there aren't many people will use this feature in production environment.
- liotier 9y agoYou should see what large Oracle shops in the enterprise segment do with PL/SQL, though whether they have gone too far is open for debate...
- bluejekyll 9y agoYes they have. And then it's full on vendor lock-in.
- _jal 9y agoI used to think this, but have relaxed that view over time. For constraints, validity checking, things like adding/updating timestamps, and other things that are about data integrity, about the only time I don't do that in the DB is when outside information is involved such that it can't be. Otherwise, to the extent possible, I want the datastore to only accept valid data. This goes to the notion that fixing code is easier than fixing data, so the store can not only defend itself, but also help catch bugs. There are also times when dealing with huge amounts of data that doing whatever you're doing in an SP is the only way to get decent performance. Dragging enormous tables over the network to process is sometimes really wasteful. If you're tuning indexes and whatnot against that model, you're already changing the DB, and doing so at a level that is implicit rather than explicit, and in ways that can change out from under you (if the statistics change).
- cat199 9y ago> it's harder to maintain and harder to do release management How is this any different than anything else where DB data & application logic have to be kept in sync? version control + loader/change scripts should handle it, no?