I hate to open a can of worms on a side topic, but you did bite....
It has its pros and cons. You've covered the big cons, not portable
(with MySQL++ I'm tied to MySQL anyway), source-control (yes, that has
to be managed and can get out of control). Regarding ugliness, my
saying is "you can write crap in any language" ;-) MySQL's SPs are young
and do have limitations (e.g. no constants!) but hopefully they'll catch
up with the big boys.
Some of the pros are:
The C++ is insulated from the schema. The database can be
optimized tables, split, combined, etc. without changing code. Fixes to
SPs can be made on-the-fly.
Performance can be greatly improved by avoiding multiple round
trips to SQL server. I was first sold on SPs working on a big Oracle
project. It was a data-heavy financial project that had lots of calls
from C++ into the database with little business logic between SQL calls.
We moved that into SPs and got about a 10x increase in performance by
simply porting the chunks of C++ to T-SQL SPs (your performance may
I'm sure this topic has been beat to death on the Internet, these are
just my $.02. I think it all depends on your app and the skillset of
your developer. On our team the C++ server guys are quite capable of
writing their own SPs. We have many SPs that have to gather data from
several tables, and get a result or update another table, or move data
around. With one tiny call to the database we can do a lot of work
without transferring datasets from SQL box to server box.
One DBA we had was of the 100% SP mindset. Every insert, update,
delete, and select *had* to be a SP. That was a real pain.
From: Warren Young [mailto:mysqlpp@stripped]
Sent: Tuesday, January 27, 2009 9:42 PM
To: MySQL++ Mailing List
Subject: Re: Calling stored procedure and returning result in SSQLS
Jim Wallace wrote:
> I use SPs almost exclusively with MySQL++.
Okay, I'll bite. :)
My ignorant view is that stored procedures are software written in a
quasi-proprietary language that's less powerful and arguably even uglier
than C++, which must be stored in the DB engine where it's resistant to
source code control and other change management practices that overcomes
If by some wild chance I've managed to capture the essence of the issue,
what compelling value do you find that outweighs these problems?
If, as seems more likely, I'm wrong in my assessment, I'd appreciate a
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus