I ignored the case you mentioned and I should have stated it.
However, if an app is now moving web based and the user base grows exponentially a stored-procedure based system will not be able to scale to handle the growth.
Something else I didn't mention (out of lots of other reasons) is that a corporation wishing to reuse its business logic should not be placing its business logic in stored procedures which can't be scaled and can be very hard to maintain if you use more than one database vendor.
Web Services are a great solution and in most cases should be used instead of stored procedures because web services use http (everything supports this), and have bindings for most languages.
Note that Linux web services using Tux are several times faster than JDBC/ODBC/Java RMI/CORBA and even quite a bit faster (and less CPU intensive) than rolling your own sockets based protocol.
I agree that it's deficient. Though I like MySQL I can not use it, nor could I recommend it (yet) for my employer's enterprise nation-wide and international fortune clients.
About your earlier comment, it would seem you have simply affirmed my point. If you had to grow from a 200MHz Pentium to an 800K RS/6000 farm just to get a 700% increase you have fallen into the scalability trap I was trying to explain: given your current scalability/cost ramp (which isn't linear) most applications (yours may not) on such a ramp will soon not be able to scale no matter how much money you pump into it.
Relational databases are slow and unscalable.
Can I add another box and double my query or
insert capability? No.
But, I can add another app server and theoretically double my ability to execute code. People who design enterprise applications to use stored procedures are giving up their ability to scale. The exception to this rule is when stored procedures perform aggregations, and time series analysis. However, I will go so far as to say that using a relational database to perform ad-hoc analysis is a stupid thing to do and a billion dollar industry has grown up around solving this problem in a better way (OLAP).
ALL enterprise applications I've seen that use stored procedures were failures because they could not scale. They had to be rewritten and redesigned from scratch.
As other posters have said, this is not much to be happy about.
Slashdot Mirror
I ignored the case you mentioned and I should have stated it.
However, if an app is now moving web based and the user base grows exponentially a stored-procedure based system will not be able to scale to handle the growth.
Something else I didn't mention (out of lots of other reasons) is that a corporation wishing to reuse its business logic should not be placing its business logic in stored procedures which can't be scaled and can be very hard to maintain if you use more than one database vendor.
Web Services are a great solution and in most cases should be used instead of stored procedures because web services use http (everything supports this), and have bindings for most languages.
Note that Linux web services using Tux are several times faster than JDBC/ODBC/Java RMI/CORBA and even quite a bit faster (and less CPU intensive) than rolling your own sockets based protocol.
Mph:-) That's so funny it deserves a response:-)
I agree that it's deficient. Though I like MySQL I can not use it, nor could I recommend it (yet) for my employer's enterprise nation-wide and international fortune clients.
About your earlier comment, it would seem you have simply affirmed my point. If you had to grow from a 200MHz Pentium to an 800K RS/6000 farm just to get a 700% increase you have fallen into the scalability trap I was trying to explain: given your current scalability/cost ramp (which isn't linear) most applications (yours may not) on such a ramp will soon not be able to scale no matter how much money you pump into it.
Relational databases are slow and unscalable.
Can I add another box and double my query or
insert capability? No.
But, I can add another app server and theoretically double my ability to execute code. People who design enterprise applications to use stored procedures are giving up their ability to scale. The exception to this rule is when stored procedures perform aggregations, and time series analysis. However, I will go so far as to say that using a relational database to perform ad-hoc analysis is a stupid thing to do and a billion dollar industry has grown up around solving this problem in a better way (OLAP).
ALL enterprise applications I've seen that use stored procedures were failures because they could not scale. They had to be rewritten and redesigned from scratch.
As other posters have said, this is not much to be happy about.