First off: Thank you for your rant. It's a one based on experience. If if folks don't agree or are quick to have a comment: I appreciate your frustration. Now my turn for a comment or thought: I'll keep it general as possible. I went into a database seminar related to a now defunc product that was one of the best analytic tools I've ever used in my entire career.. and this was in 2001! I've yet to see it's match today. It was called "BroadBase" and it was awesome. Anyway; before they were bought and the software purposely taken off the market even though it didn't compete with the new owner's products... I went to a seminar they hosted. In that seminar we covered and discussed things like data-marts, data ware-housing, reporting, applications, various database vendors and design in general. Some of the major points I remember quite clearly was where do you put your business logic: In the database or in the application? Now there are folks who say one, the other or both. Here were the things that interested me: they aren't answers.. but they are good things to consider when deciding: 1: Placing Business Rules and logic into the database (foreign keys, PL SQL etC) to help deliver information and protect data integrity put more reliance on the particular Database vendor. (Puts responsibility for data integrity on the database's shoulders) 2: Putting business rules and logic into your application makes your application less dependent on the specific DBMS your using 3: If multiple applications use the same database: Option 1 seems like a good option but putting business rules into a shared code base all systems can leverage gives benefits of option 2 but might be impossible or too difficult to implement enterprise wide. So for me: I don't have an argument for one way or another. I'm also in agreement with other comments in this thread to the tune that it's not necessarily tools but skill that makes the difference in quality for finished systems. I also am slow to bash folks for ugly systems I'm asked to fix because without knowing what environment the folks were working under: budget; time; boss; requirements; chief architect passed away mid project... god forbid... My Opinion is: There isn't a one size fits all solution: consider ALL details; short term and long term goals of the project; consider your team, your budget, and make it happen as best you and your team can!
Know way too many languages... master of none!