tag:blogger.com,1999:blog-4015078625407292958.post5541885913578163926..comments2008-12-05T15:34:11.469-08:00Louisnoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4015078625407292958.post-85029538035121325432008-12-05T15:34:11.469-08:002008-12-05T15:34:11.469-08:00Thanks for your comment, Anne.<BR/><BR/>You are absolutely right when you say that business logic has no place on the database side of of your application, and I should've mentioned it!<BR/><BR/>I am just amazed at the amount of information we can get out of a properly designed database and how fast SQL can get it for us.Louishttp://www.blogger.com/profile/15834808621872557921noreply@blogger.comtag:blogger.com,1999:blog-4015078625407292958.post-20934737632064441432008-12-05T15:29:14.775-08:002008-12-05T15:29:14.775-08:00SQL sure can do a lot, esp. T-SQL (I've written many a logic-filled sproc in my time) but you do have to be careful with that... as I'm sure you're reading, T-SQL has a fairly full set of loops, branching, and even some exception tools, and it's can be tempting to end up with business logic in your DB. It just needs to be said that logic is much harder to test in the DB, and may even be outside of your standard versioning/change control system-this is a risky set of affairs, and something to avoid if possible. <BR/><BR/>I will say that it's certainly still a good idea to get very familiar with what SQL can do, esp. if you have no DBA. If a query is running slowly, it's important to know why, and what can be done. (take a look at indexing and understanding query plans) Besides, even when using an ORM that can make queries, you'll want to know how to work with views and triggers to ease working with ugly tables while transitioning to better structures, or if you end up with a query that your ORM just isn't writing efficiently (rare, but I hear it happens), you might be able to handcraft something better.Annehttp://www.blogger.com/profile/03729624916836273494noreply@blogger.com