> That seems un-pragmatic to me. IMHO if any business logic needs > access to lots of data, it's best implemented by code that > resides in the database itself, close to the data. I once had a There is a balance: ETL and reporting code is often iterative and can be more flexable in an external language. Getting the balance right takes some thought, planning -- both of which are usually in short supply on software projects. Testing database code and structures is easy in PG using TAP: <https://blog.2ndquadrant.com/using-postgresql-tap-framework-extensions/> Also easy to test database contents and emedded logic: <https://www.slideshare.net/lembark/object-exercise> Putting all or no logic into the database as a knee-jerk reaction is usually a mistake. Especially with PG testing is easy using extensions and schemas to segregate the code/data being tested. At some point the data will have to hit code, especially in ETL or reporting logic. Balancing the work in and out of the database just makes sense. Which is probaly why it doesn't happen... -- Steven Lembark 1505 National Ave Workhorse Computing Rockford, IL 61103 lembark@xxxxxxxxxxx +1 888 359 3508
