I think one of the reasons that databases and their tools have lagged behind other software development is that it still requires human expertise to make a database perform very well, so automatic tools become more of a problem than a solution at this time.
Yes, there are ORM tools that can write a good query, but a decent DBA still needs to review them if you want the code to consistently perform well. It takes as long or longer to review automatically generated code as it does to write it yourself in the first place, if you know what you're doing.
Sure, when I want to build a view, I can drag icons for tables onto a screen, drag arrows between column names in them to define joins, check boxes to put the columns I want into the select clause, and enter formulae into a set of fields to build a where clause. Then I have to review what this creates, which means reading horribly formatted text, making sure it's right, and then clicking the save button.
Or I can drag the table names into the text editor, drag the Columns folders from the object explorer into the same, and then type up the rest of it myself. It's faster, it ends up formatted better (equals "the way I like it" and/or "the way it's required to be because of company standards"), and it gets the same end result.
Of course, it helps that I type very, very fast, but that's just a slight advantage, the rest of it is an experience advantage.
But the underlying reason this is needed is because database performance just plain sucks when you leave it on its own.
What will happen to database performance when hard drives are replaced with something a thousand times faster? How about a million times faster?
What will happen when multi-table indexes become less of an overhead and more readily available for use? How about when the database detects the need for these indexes and builds them on the fly on its own? And when it can do so correctly?
How about a better implementation of OR in Where clauses?
As these kind of things happen, it will be less and less critical for database code to perform well, which will make it more and more likely that more automatic tools will be more useful.
To compare that to application development in .NET or whatever, take a look at how efficient, fast and powerful code written at a very low level, like C, can be. Procedural code will generally outperform object-oriented code by a significant margin. But OO code is more common in application development because hardware, compilers, libraries, etc., have become powerful enough to make up the difference as far as human users are concerned, and OO code is generally easier to learn, easier to write, much easier to collaberate on, etc.
The database remains the biggest performance issue in most application development. It's where the heavy lifting takes place. It's where most of the IO takes place. It can't be offloaded to the GPU. Etc.
Till that's no longer true, I think "more sophisticated" database dev tools aren't practical in too many places.
But I also think it's catching up fast. And the better tools are evolving right at this moment.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon