September 28, 2010 at 9:14 pm
Comments posted to this topic are about the item The Design Investment
September 29, 2010 at 1:57 am
That is a pretty apt analogy IMO. Tiles that you lay yourself can be a little fumbled/imperfect, but a tile-layer would be able to do a professional job. Would you let the tile-layer install your central-heating? He may have an idea of how it could be done, but it could be just as fudged as if you do it yourself.
Now consider the programming profession; most see a programmer and think he can do it all (esp. managers)- it is all computers and code anyway! A C# coder who has mastered that language cannot necessarily design a database, so expecting him to do so and produce a product that is as good as a database architect is foolish.
I accept that a developer should have experience in more than one area and strive to learn but there is a limit to the practicality of it.
I read your editorial as if developers that work on database design have taken that task on voluntarily. I think that that is a minority case in the real world. Many developers work on a front-end and are then "volunteered" into the back-end DB-design too. These people do not have the time to learn something like SQL Server in depth to allow them to work with it optimally.
I am a fulltime development DBA and spend a lot of time extending and perfecting my knowledge of SQL Server. If I also had to write C# applications for my company, I would have to let one of the two slip just to keep up with the expected output!
Regards,
WilliamD
September 29, 2010 at 2:34 am
The attitude amongst managers seems to be that it is "just" a database and you "just stick the data in there" and it doesn't matter how.
More education is essential on how it matters that the database is properly structured and how it can reduce query time and thus improve the users' experience.
September 29, 2010 at 6:27 am
I don't know about everyone else, but I'm seeing less and less data design these days as we use more and more ORM tools. They "do the design for you"... yeah I can't say it without laughing, but that's the attitude that's been pretty prevalent lately. I'm sure we'll see a pendulum swing the other way at some point. But right now, design is a dirty word around here. It slows down development.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 29, 2010 at 6:49 am
I am currently stuck in the scenario Old Hand describes......with the addition of "rock star" developers who design their own databases, in Access, do all of their .Net development against it.
Only when they feel it is ready for UAT do they send the Access file to me "to upsize" or they do it them selves on a dev box and ask the dba to backup/restore to another box for UAT.
The DBA then becomes the bad guy for holding things up by wanting database changes. The devs are perfectly happy with columns named "Default", "PostalCode/Zip Code".....or tables named "Tbl Inventory Items in Error / Not Found".
I am at my wits end trying to get this place running properly. I've only been here a year and a half and feel like I'm making no progress as everything is a battle. 52 servers - 1200+ databases - 2 dba's - the other dba was hired 5 months ago - they've gone through 5 dba's in 5 years.....nobody is "getting it" 🙁
September 29, 2010 at 6:53 am
I agree with the angle of this article. However, I am a developer. I mainly write entire applications and websites by myself. I used to lead a team. Regardless of which setting I am/was in, I always make sure that the database design gets the utmost consideration. I took the time long ago to learn everything that I could about good DB design.
I am a stickler for consistency and standards, so I have always had guidelines written up for my team (even when my team is just myself) on how to handle just about everything from naming variables, functions, classes, columns, tables, indexes, to how to arrange an argument list, use of tabs vs. spaces, and where to put block begin/end indicators (on the declaration line vs. below it, etc.).
Attention to proper design and careful implementation are key to the long-term success of a project. I always find myself correcting colleagues' inconsistent column names, or mixing tabs with spaces. The usual response is, "What does that matter? I just want to know if you think it will work!"
It seems as though many people in our field do not value organization, planning, and general forethought. It's a shame. The software suffers and its users learn to accept certain (inexcusable) patterns in its life-cycle.
September 29, 2010 at 6:58 am
I also partially agree with the comments made against ORMs. I feel that many developers use those tools to generate the DB and that makes me shutter. As a developer who uses ORMs plenty, I make a point to design my database correctly by hand (the horror). Afterward, I force the ORM to use my proper design.
In the end, this way of working with ORMs makes everything run so much smoother. A good ORM knows how to work with a good DB design if it is configured properly. That means someone with a good working knowledge of the DB schema absolutely must be one of the folks configuring the ORM. Whether that is a developer with a really good understanding of DB design, or a DBA that gets OOP, it doesn't really matter. So long as the ORM is not allowed to do whatever it wants and is "told" how things work in this particular setting.
September 29, 2010 at 6:58 am
Grant Fritchey (9/29/2010)
I don't know about everyone else, but I'm seeing less and less data design these days as we use more and more ORM tools. They "do the design for you"... yeah I can't say it without laughing, but that's the attitude that's been pretty prevalent lately. I'm sure we'll see a pendulum swing the other way at some point. But right now, design is a dirty word around here. It slows down development.
Holy cow, that's a nightmare.
Why don't you get the developers to at least install SQL Server locally and use that for development. That would avoid the "upsizing" issues.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 29, 2010 at 7:00 am
Matt S. (9/29/2010)
I also partially agree with the comments made against ORMs. I feel that many developers use those tools to generate the DB and that makes me shutter. As a developer who uses ORMs plenty, I make a point to design my database correctly by hand (the horror). Afterward, I force the ORM to use my proper design.In the end, this way of working with ORMs makes everything run so much smoother. A good ORM knows how to work with a good DB design if it is configured properly. That means someone with a good working knowledge of the DB schema absolutely must be one of the folks configuring the ORM. Whether that is a developer with a really good understanding of DB design, or a DBA that gets OOP, it doesn't really matter. So long as the ORM is not allowed to do whatever it wants and is "told" how things work in this particular setting.
No disagreement. I'm not against ORMs in any way. I'm just against the way they are used by lots of developers. Basically they're turning everything into OOM (Object-Object-Mapping) as a way to eliminate the database problem. Instead, of course, it's making things worse.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 29, 2010 at 7:07 am
@Grant
I hear you. I've seen DBAs light up with some glimmer of hope when I'm hired to reign in developers gone wild. It's because I sell my services similarly to how I just described things above.... The database comes FIRST!
No matter how good the code is, the whole system can become a cesspool of hatred and loathing if the DB is treated like an afternoon Access class at a community college. Most developers only see it from their side of the fence. "It's just data in a bucket." or "I can do it with text files just fine!"
Oh, I'm going to be sick just thinking of it.
September 29, 2010 at 7:12 am
How many people have had their fingers in the pie? In my environment, our databases are as old as the contract (8 years). There have been numerous people, of varying abilities, in these databases over 8 years. There is no way to insure consistency and quality if it's not a top priority of management. Especially management that understands the problem.
September 29, 2010 at 7:12 am
Matt S. (9/29/2010)
@GrantI hear you. I've seen DBAs light up with some glimmer of hope when I'm hired to reign in developers gone wild. It's because I sell my services similarly to how I just described things above.... The database comes FIRST!
No matter how good the code is, the whole system can become a cesspool of hatred and loathing if the DB is treated like an afternoon Access class at a community college. Most developers only see it from their side of the fence. "It's just data in a bucket." or "I can do it with text files just fine!"
Oh, I'm going to be sick just thinking of it.
Heck, I don't need it come first, I'd just like it to be a consideration at all. I keep hearing the db referred to as "the object persistance layer." And yeah, it makes me more than a little bit queasy when I hear it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 29, 2010 at 7:34 am
In today's fast paced environments, it is the Business that dictates technology, unfortunately! When that happens, best practices are normally thrown out the window and cutting costs and unrealistic timelines are what become priority, causing bad designs and software applications that can barely do what is required.
Not until a disaster (or management not able to run some report) happens, the focus then, temporarily, shifts to getting some proper design and requirements in place to get by the issue at hand only to later go back to the laissez faire attitude!
September 29, 2010 at 8:15 am
salman.samad (9/29/2010)
Not until a disaster (or management not able to run some report) happens, the focus then, temporarily, shifts to getting some proper design and requirements in place to get by the issue at hand only to later go back to the laissez faire attitude!
That's just it! Our industry's business takes a reactive approach to building software. Even when things explode, it's nearly impossible to convince others that a proactive approach likely would have avoided the "mad scramble" to fix something that should have been done right the first time.
I find that when trying to prove such points to management (or even my developer colleagues), it is best to show cost estimates. Estimate the cost it would have taken to put the extra effort in vs. the cost it took to fix the issue afterward. Try to account for any lost revenue due to the explosion too.
September 29, 2010 at 9:15 am
Then there's the DB that WAS designed well, but that person left and various people have been asked to "just add this" in the years since...
Viewing 15 posts - 1 through 15 (of 63 total)
You must be logged in to reply to this topic. Login to reply