Re: Working with tables, best method

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Alan Campin wrote:
> <snip>
> Then you do the ultimate no-no: you attempt to put some business logic 
> in your SQL.
> </snip>
>
> Huh? I have been putting the business logic in the database for thirty
> years. What possible reason would I have for putting the business logic
> in the program when it can go into the database and be expressed through
> sql?
>   
Well, first off, there are a number of reasons not to, but they're 
mostly programming style preferences.

I disagree with just about all of the standard SQL "advantages" from 
database independence to readability.  I don't need database 
independence, and I find SQL littered with CASE statements to be obtuse 
and unreadable.  But see, these are opinions.  The only fact in the 
discussion, and the one that every SQL evangelist says is unimportant, 
is that SQL is slower than native I/O for certain classes of operations.

Whenever an SQL person says that, the rest of their statement is pretty 
much lost on me, because the only thing that matters is the end is 
performance.  As soon as you start giving up performance in order to 
make writing and maintaining the code easier, you are on a slippery slope.

In my opinion.

Joe