Stored Procedures
I come to find that i am pushing more and more of my logic into the database.
Pros
- Much simpler coding
- Fewer database hits
- Great logic for handling related updates e.g. when adding an order item, creating an order first
- CURSORS! (Yes, there are times when a cursor is a GOOD thing!)
Cons
- Portability out the window (but then again, database choice is a decision not made lightly!)
- Aah -- can't quite think of another!
Pros
- Much simpler coding
- Fewer database hits
- Great logic for handling related updates e.g. when adding an order item, creating an order first
- CURSORS! (Yes, there are times when a cursor is a GOOD thing!)
Cons
- Portability out the window (but then again, database choice is a decision not made lightly!)
- Aah -- can't quite think of another!
posted by M @ 10:36 AM
2 Comments:
At 12:29 PM,
Anonymous said…
>>Yes, there are times when a cursor is a GOOD thing<<
Sounds blasphemous :-) When is a CURSOR a good thing?
At 4:26 PM,
M said…
When you have nested, related records that have to be treated as a unit. E.g. if you have an invoice table and an invoice items table, and you want to rollback the transaction ,factoring in that you also have to update the stocks table (add the returned stock items) as well as the accounts payable table (deduct the expected cash)
Post a Comment
<< Home