Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

The Design Investment Expand / Collapse
Author
Message
Posted Tuesday, September 28, 2010 9:14 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:49 PM
Points: 31,161, Visits: 15,607
Comments posted to this topic are about the item The Design Investment






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #994905
Posted Wednesday, September 29, 2010 1:57 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: 2 days ago @ 3:29 AM
Points: 449, Visits: 1,863
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
Post #994972
Posted Wednesday, September 29, 2010 2:34 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 8:16 AM
Points: 559, Visits: 1,200
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.
Post #994989
Posted Wednesday, September 29, 2010 6:27 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 6:46 AM
Points: 13,862, Visits: 28,258
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
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #995122
Posted Wednesday, September 29, 2010 6:49 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: 2 days ago @ 8:01 AM
Points: 31, Visits: 910
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"

Post #995153
Posted Wednesday, September 29, 2010 6:53 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, July 14, 2011 6:53 AM
Points: 199, Visits: 60
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.
Post #995160
Posted Wednesday, September 29, 2010 6:58 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, July 14, 2011 6:53 AM
Points: 199, Visits: 60
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.
Post #995165
Posted Wednesday, September 29, 2010 6:58 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 6:46 AM
Points: 13,862, Visits: 28,258
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
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #995166
Posted Wednesday, September 29, 2010 7:00 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 6:46 AM
Points: 13,862, Visits: 28,258
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
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #995174
Posted Wednesday, September 29, 2010 7:07 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, July 14, 2011 6:53 AM
Points: 199, Visits: 60
@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.
Post #995183
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse