As far as stored procedures go, I'm heavily involved with the internet
banking product for one of Australia's banks, and, while its not a rails
app (its an expensive web framework, cause banks have like heaps of
money), all of the DB interaction, such as it is, is via stored
procedures pretty much. However, the DB isnt used for account access - a
mainframe is used for that, with an expensive messaging system (cause
banks have like heaps of money) - the DB is used pretty much for
ancillary functions like BPay, statement print requests etc.
Now I'm not privy to the reasons why SP's are the chosen architecture,
but I'm willing to trust the DBA's and eBanking developers that it
wasn't a trivial decision, and despite the awkwardness this adds to the
development process, the runtime concerns are their driving focus.
HTH
L
On 25/01/10 11:44 PM, Jason Stirk wrote:
Many folks give the excuse that MySQL is a "toy" database, as the
older versions lacked stored procedures, triggers and the like. Whilst
that's been changed recently, realistically, I'm prepared to call
bullshit when this justification comes up in the context of web dev:
YAGNI anyway...
In fact, I'd be very interested to talk with any Ruby web developer
who's ever needed stored procedures, triggers, or anything like that.
I'm genuinely interested to know what situation could have called for
them in the web world, and how they actually benefited your project.
(Not to mention that the idea of code in the DB layer scares the crap
out of me...)
--
You received this message because you are subscribed to the Google Groups "Ruby or
Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
