Submitted by Beat Vontobel (not verified) on Fri, 12/02/2005 - 03:10.
I don't want to start a flame war on this, as it's probably a matter of taste, too. ;-)
But hey, if somebody wants to vote multiple times, isn't this an error condition?
And it's just my philosophy that I like to enforce data integrity as closely connected to my actual data as it's only possible. That's the same philosophy as in OOP where you bundle data and the operations done on it.
Then you get an additional advantage: The single INSERT is by definition atomic, with an additional SELECT however you have to use transactions or do a LOCK TABLE (if you use MyISAM) to ensure that there's no other conflicting INSERT between your SELECTs and INSERTs (I don't even want to start talking about the overhead consequences of that).
I don't know too much on the actual overhead that's involved in throwing an exception from JDBC, as I'm more the Perl than the Java guy. But I hope it won't be too bad, as exceptions are a pretty common thing to use in Java as I understand it.
For the stored procedures: Yes, it's of course possible to return a value from a stored procedure in MySQL and then to SELECT that afterwards. You just end up with another query and its overhead.
But of course it's okay to use your approach as well: I just wanted to give you some arguments for Sheeri's. And I think there are quite a few if you look at this thread, and they are not too bad, are they?
I don't want to start a
I don't want to start a flame war on this, as it's probably a matter of taste, too. ;-)
But hey, if somebody wants to vote multiple times, isn't this an error condition?
And it's just my philosophy that I like to enforce data integrity as closely connected to my actual data as it's only possible. That's the same philosophy as in OOP where you bundle data and the operations done on it.
Then you get an additional advantage: The single INSERT is by definition atomic, with an additional SELECT however you have to use transactions or do a LOCK TABLE (if you use MyISAM) to ensure that there's no other conflicting INSERT between your SELECTs and INSERTs (I don't even want to start talking about the overhead consequences of that).
I don't know too much on the actual overhead that's involved in throwing an exception from JDBC, as I'm more the Perl than the Java guy. But I hope it won't be too bad, as exceptions are a pretty common thing to use in Java as I understand it.
For the stored procedures: Yes, it's of course possible to return a value from a stored procedure in MySQL and then to SELECT that afterwards. You just end up with another query and its overhead.
But of course it's okay to use your approach as well: I just wanted to give you some arguments for Sheeri's. And I think there are quite a few if you look at this thread, and they are not too bad, are they?