Re: Working with tables, best method

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