On 4 May 2016 at 12:36, Szymon Lipiński <mabewlun@gmail.com> 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
