问题
In banking sector, they use stored procedures for business logic. Their logic is moved in the db instead in business logic layer.
What is the reason that the banks insists for stored procedures ?
Regards
回答1:
The stored procedures may have been there for 30 years on the mainframe. Client languages have come and gone in the meantime.
Anyway, you have to define "business logic": a lot of "business logic" comes down to being "data integrity" rules (such as "Only set this coumn when aggregate of child rows is zero") which needs to be transactional and atomic.
Related:
- Why are mainframes still around? (SO)
- How necessary or convenient is it to write portable SQL? (SO)
- Why use Stored Procedures? (Blog)
Simply, my DB code will outlive your client code...
回答2:
That's certainly not true of many banks I have worked in. Applications in banks are just like applications in any other company, and range from being coded almost entirely in stored procedures, to eschewing stored procedures altogether in favour of something like an ORM.
As for why they might choose to put logic in the stored procedures? Sometimes it's the sensible place to do it. I know the ALT.NET crowd (or whoever the NoSQL/ORM fanbois are for your platform of choice) will have you believe that stored procedures are evil and that ORMs are the only reasonable solution, but in the real world building real applications with real differing requirements, it's not that simple.
来源：https://stackoverflow.com/questions/3270819/stored-procedures-and-banks