RE: Re: DRY principle form validations


#1

Oh man, as a dba, I can’t help but reply :slight_smile:

There are some things you simply can’t do efficiently unless you do it
on the DB. I think too often people get afraid of being forced to stick
with one DB, when in reality you probably wont switch anyway.

Since the Db is actually interpreting the TSQL code being thrown at it
and making its best guess about how to use indexes, etc. stored
procedures are particularly useful for forcing a compiler to work one
way or another. In addition, with large tables, or queries that require
complex logic, you simply cannot do it on the client side with any
efficiency.

I feel better :slight_smile:

-B

PS: I love this example… Most people aren’t aware that the join order
can effect the query time.

  1. Take this query.
    Select * from large_table lt join small_table st on lt.id=ct.id

  2. On most RBDMS systems you can make it more efficient by simply
    switching the join order.
    Select * from small_table st join large_table lt on lt.id=ct.id


#2

Well, :o) I’m not going to send us into a fracas, especially considering
I’m talking to a dba here ;o) and you’re thoughts on the matter are
influenced by being a dba.

We’ll just have to agree as gentlemen to disagree. lol

I haven’t see much I couldn’t do efficiently on the middle tier. As
stated in my previous posting, we supported three or more database
engines simultaneously. Having a bunch of processing done in stored
procedures just doesn’t work for us as a result.

Could you give examples of what is done more efficiently on the database
server? We didn’t run into complex queries as you describe. We just
stuck with the KISS principle and things worked fine.