On 4 May 2016 at 12:36, Szymon Lipiński <mabewlun@xxxxxxxxx> wrote: > From my perspective there is one more thing: when I tried, in couple of > companies, to move some part of the logic to a database, then usually the > management said "no, that's not doable, as we will have trouble with finding > good sql programmers later", and we were still writing all the logic outside > the database. "Finding good programmers later" will always be hard. There are less of them about than Human Resources would like to believe. Putting your logic in a different layer or in a different language over the top of SQL doesn't mean you won't need good programmers later; quite the reverse, because now you need programmers who are both strong in SQL _and_ good enough to understand the layer you've added on top. On the other hand, if you're planning on putting _some_ of your logic into the database, then I probably see where they're coming from. If you give full database access to application developers (rather than providing them with stored procedures that perform the tasks for them) then they will be surprised as hell when the database does something they weren't expecting because of some business rules that are in a fourth-level trigger somewhere. The sensible way is to do it as John wrote - to restrict access rights to everyone except admin to calling functions only. That way the functions are written by the people who are paid to understand the business rules and the data behind it, and the application developers can ask those experts to do the heavy lifting for them. Having to persuade management that they should no longer be able to connect the database to MS Access and make changes that way will usually put an end to that pure model, though. :) Geoff -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
