Re: can this reject bad data?

On Thu, May 8, 2014 at 8:32 AM, Needles,Stephen J
<SNEEDLES@xxxxxxxxxxxxxxxx> wrote:

I wrote it for fun. I excluded RPG because I wanted to exercise
my SQL skills.

OK, I get that. But now that you've got this piece of SQL which is,
frankly, less than elegant, should that go into a production UDF?

Maybe it's a minor point, maybe I'm an overly picky "craftsman"
toolmaker. But looking at things like readability, maintainability,
performance, and robustness, is that SQL exercise really what you want
in production?

Especially when a few lines of RPG can do the same thing, more
readably, and probably execute faster? And is more
modifiable/extensible should the need arise?

Maybe it's a subtle point, but I strive to only put code in production
which I believe is a decent model for others to learn from and
emulate. I guess that sounds cocky or presumptuous. Fair enough.
Let's say I prefer not to put anything into production which knowingly
decreases the quality of the codebase. You yourself have said that
you don't think your SQL solution is the cleanest way to do it. You
sound like you know that the artificial SQL-only constraint was
blocking off better solutions.

John