November 14, 2009 at 10:10 am
Guess we will have to agree to disagree on this one. In my world, 93.7% of the developers will take the easiest way to slap code together as quick as possible. And many if not most 'constructs' that enable the dev to write code more quickly are in my experience bad for database performance. Oh, and most of the rest of the devs who do WANT to take the time to write good database access code cannot do so due to time constraints.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
November 14, 2009 at 12:53 pm
TheSQLGuru (11/14/2009)
Guess we will have to agree to disagree on this one. In my world, 93.7% of the developers will take the easiest way to slap code together as quick as possible. And many if not most 'constructs' that enable the dev to write code more quickly are in my experience bad for database performance. Oh, and most of the rest of the devs who do WANT to take the time to write good database access code cannot do so due to time constraints.
I would say 93.7% is rather high because about forty percent of new development uses relational model designed by RDBMS experts who do only database designs an application developer in such cases uses the ERD as is and cannot make changes without data architect approval. There are problem codes in all layers of software development saying one set of developers only write bad code is a personal opinion not related to the actual issue. Your services being needed is an employer's choice hire skilled developers with correct schedule or later pay a performance tuning expert who will do only 10% more SQL Server based performance work than the skilled object relational developer.
Kind regards,
Gift Peddie
November 14, 2009 at 4:39 pm
Gift Peddie (11/14/2009)
TheSQLGuru (11/14/2009)
Guess we will have to agree to disagree on this one. In my world, 93.7% of the developers will take the easiest way to slap code together as quick as possible. And many if not most 'constructs' that enable the dev to write code more quickly are in my experience bad for database performance. Oh, and most of the rest of the devs who do WANT to take the time to write good database access code cannot do so due to time constraints.I would say 93.7% is rather high because about forty percent of new development uses relational model designed by RDBMS experts who do only database designs an application developer in such cases uses the ERD as is and cannot make changes without data architect approval. There are problem codes in all layers of software development saying one set of developers only write bad code is a personal opinion not related to the actual issue. Your services being needed is an employer's choice hire skilled developers with correct schedule or later pay a performance tuning expert who will do only 10% more SQL Server based performance work than the skilled object relational developer.
1) you will note that I did NOT restrict my statements to front end/middle tier developers. I include tsql/database developers in my comment. SQL Server (and Microsoft products in general) are simply sooooo easy to develop against/for that poor design and code is the norm, not the exception.
2) not sure what companies you have interacted with but in 12 years of database consulting (and several years of dev/admin before that) I can count on 1 hand the number of clients I have interacted with that did even a moderately serious attempt to model database stuff and use dedicated database engine developers. And only one of those did a decent job of it.
3) there are, in my experience, VERY few 'skilled database developers' out there, and most of the good ones are very much taken care of by the employers they have that recognize their worth. So current employers don't have the option of hiring good employees - there aren't enough of them on the job market, even in this downsized economy.
4) Your last point is so far off the mark I don't even know how to respond to it. I will just chalk it up to you and I (along with numerous other tuning experts on this forum) clearly not moving in the same circles and experiencing the same things at many, many clients. I consider it a personal and professional disappointment if I don't improve most things I touch at my clients at least an order of magnitude - usually 3+ orders of magnitude.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
November 14, 2009 at 5:27 pm
4) Your last point is so far off the mark I don't even know how to respond to it. I will just chalk it up to you and I (along with numerous other tuning experts on this forum) clearly not moving in the same circles and experiencing the same things at many, many clients. I consider it a personal and professional disappointment if I don't improve most things I touch at my clients at least an order of magnitude - usually 3+ orders of magnitude.
CA sells ERwin while IBM sells Rational Rose as part of their tools in software engineering companies these tools are in a network folder for developers to use and in none software companies a developer can ask for ERwin to be approved. If these expensive tools are used correctly in most cases your services are not needed. I also don't accept it that there are very few skilled database developers because businesses look to cut cost get cheap and hire unskilled people.
My point is if I am hired with the correct schedule you and other performance expert services are not needed, what I find however is people who cannot write code saying a report to change a business structure is due in one week, an employer wants one to six months work in one week it is what the employer paid for not the actual report so other services are needed. In this site there are many of us that know all areas of performance tuning at very low level just choose to use all of SQL Server instead of tuning only.
And in SQL Server 2000 Microsoft hired unskilled people, the one I met did not know the difference between UNION and UNION ALL to write the performance tuning book.
Kind regards,
Gift Peddie
November 15, 2009 at 4:50 am
[SET VENTING ON]
A vendor I've been forced to deal with late in a project used NHibernate to connect to a database he designed (for us).
When facing major performance issues I've been asked to have a look at it.
So I scheduled a meeting and wanted to talk to their SQL programmer in charge.
Frightening answer:
"We don't have anybody specifically knowing SQL Server. We do have a couple Oracle folks though, but they are not involved. Everything is done by our application programmers and since we're using NHibernate, we don't really care about the database issues. NHibernate will take care of it.
As a side note: The few Oracle programmers we have in house will be sent to training for C# and Java since we don't need any database programming level anymore, now that we have NHibernate."
After they learned about indexed views, ITVF's, set based approach to eliminate their extensive use of cursors a.s.o. they've been faced with a performance gain of the app by a factor of 20 to 50. Did that make them rethink their overall opinion? Not a bit.
Whoever think that "the market" will sort such companies out, most definitely is wrong...
[SET VENTING OFF]
November 15, 2009 at 8:35 am
CA sells ERwin while IBM sells Rational Rose as part of their tools in software engineering companies these tools are in a network folder for developers to use and in none software companies a developer can ask for ERwin to be approved. If these expensive tools are used correctly in most cases your services are not needed.
Yet another incredible statement. I will venture to say that at LEAST 75% of all database designs written to be housed in sql server are done by entities with NO modeling tools in place other than what comes with Microsoft products. Even more importantly the schema is just one facet of performance issues. Bad code, of which there is an essentially unlimited amount in the world, can take the best schema and best hardware and grind them to a pulp.
One need look no further than Sharepoint to notice that supposedly good development shops can still put out horrid schemas and code.
Anyway, enough of this dead horse for me. You live in your world and I live in mine and n'er the two shall meet.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
November 15, 2009 at 10:17 am
Heh... I'll say it all "Depends" and managers really need to pay attention to this.
Like Lutz and Kevin, my experience has been that most people just don't know they have a performance problem (until it's too late) because they don't really know enough about the database engine which is why they're using NHibernate or Hibernate or any one of a dozen other tools to being with. 😉 They judge whether or not they have a performance problem by setting up SLA's like "5 seconds to return the data to the screen". What's wrong with that? Nothing... unless you know it can be done in 0.5 seconds and that 0.5 seconds is going to scale a heck of a lot better. And that's my biggest issue with things like NHibernate... everyone is happy because schedule is met because some GUI (or other) developer can make some working code very quickly. No one is aware of any so called performance problems because of a terribly long 5 second SLA. Then, one day... BOOM!!! Even that can't be met.
Now, don't get me wrong... I've seen some outstanding, very fast, highly scalable, RAD code that folks have created using the likes of NHibernate... but it's been the exception rather than the rule. What I've seen is that a lot of folks store a pot wad of data in "cache" on the web server to get the performance they really need. Guess what happens when that "cache" sours or you bounce the web server(s) for some (any) reason? Guess what happens when there's no more room to add the data for the latest feature?
The trend appears to be that a lot of companies don't think they need data "Ninjas" on board nor the pay to go with them. When they do eventually hit the wall on performance, then they wonder why a "consultant" costs so much and why it takes so long to fix everything. I worked at a company for 4 years doing nothing but fixing previous mistakes... how much money do you think they saved by meeting schedule without a data "Ninja" on board? How many customers do you think they ticked off (and left) because they couldn't even meet a 5 second SLA anymore?
So, like I said... "It Depends". You WILL pay one way or the other... but when do you want to pay? Once you have customers that will drop you like a hot potato at any sign of trouble? Remember, "If you want it real bad, you'll likely get it that way" and technical dept will always need to be paid sometime in the future either in lost customers, someone that can fix the problems, or both. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
November 15, 2009 at 10:41 am
In my opinion the problem are not the ORMs but more some of the managers and architects. An ORM is a tool, nothing more. In early days everything was done in stored procedures or even custom client side SQL statements; often by front end developers who had no clue about databases. Results have been ugly statements with many open doors for SQL injection and ugly SQL statements with bad performance. One day there came those shiny ORMs and managers and architects thought (and think) they don't need database experts and SQL any more.
As I already wrote, I'm a friend of ORMs. They can handle a bunch of simple queries and they are nice to create (non SQL) source code when setting up a domain model. Nevertheless, they are just tools and they have their boundaries (and not too less!).
November 15, 2009 at 11:40 am
I have never said NHibernate is good I had problem with their documentation that says it can work with all RDBMS without database knowledge and we all know that is just plain wrong. But there are ORM tools that supports each RDBMS separately and those are decent tools for application development.
I have found employers will pay very high for a lot of other support employees in projects and want to pay low for the developer who is the hired hand of the project. These are the projects that later hire people to clean up code because the actual development process was crappy to start with.
I will not comment about SharePoint because I also have problem with many features of the product but being Asp.net developer I can make changes as needed in SharePoint.
Kind regards,
Gift Peddie
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply