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 ««12

things to know when designing a new database Expand / Collapse
Author
Message
Posted Tuesday, January 22, 2013 3:50 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 4:14 PM
Points: 13,126, Visits: 11,964
ScottPletcher (1/22/2013)
Sean Lange (1/22/2013)
GilaMonster (1/22/2013)
Sean Lange (1/22/2013)
ScottPletcher (1/22/2013)
DiverKas (1/22/2013)
1) Do NOT let your C#/VB/ASP/Pascal guys design the database.
2) Do NOT let your DBA's design the database.
3) Hire a Data Architect.

Just saying. The first 2 groups have very biased views of how data should be structured for VERY different reasons, neither of which usually solves the entire problem.



#2 is NOT necessarily true -- it depends on the DBA. I have long-term experience in all phases of the design process.

Also, if you hire someone who's solely a Data Architect, then you have to hire an additional person to convert the logical model into a physical model.


Neither is #1. There is no rule that says a developer is unable to design a proper database because they are a developer.


I'm a developer (SQL mostly, not front end). I'd argue that I can design at least a passably good database.


Gail we are saying the same thing. I think anytime someone starts segregating abilities based on job title they are destined to get snowballed. I too am a developer and would like to think I could cobble something usable together.



Perhaps. But I would not want someone who had not been a full-time database designer or DBA at some point to head a db design. Based on my past experiences, (almost) pure developers can't seem to forget physical details long enough to do a proper logical design. Any who could do it properly would be the rare exceptions, not the normal rule.


I agree it would be the exception but the "rules" as posted sounded like absolutes and I disagree with that sentiment.


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1410288
Posted Tuesday, January 22, 2013 4:44 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 3:48 PM
Points: 1,973, Visits: 2,919
Sean Lange (1/22/2013)
ScottPletcher (1/22/2013)
Sean Lange (1/22/2013)
GilaMonster (1/22/2013)
Sean Lange (1/22/2013)
ScottPletcher (1/22/2013)
DiverKas (1/22/2013)
1) Do NOT let your C#/VB/ASP/Pascal guys design the database.
2) Do NOT let your DBA's design the database.
3) Hire a Data Architect.

Just saying. The first 2 groups have very biased views of how data should be structured for VERY different reasons, neither of which usually solves the entire problem.



#2 is NOT necessarily true -- it depends on the DBA. I have long-term experience in all phases of the design process.

Also, if you hire someone who's solely a Data Architect, then you have to hire an additional person to convert the logical model into a physical model.


Neither is #1. There is no rule that says a developer is unable to design a proper database because they are a developer.


I'm a developer (SQL mostly, not front end). I'd argue that I can design at least a passably good database.


Gail we are saying the same thing. I think anytime someone starts segregating abilities based on job title they are destined to get snowballed. I too am a developer and would like to think I could cobble something usable together.



Perhaps. But I would not want someone who had not been a full-time database designer or DBA at some point to head a db design. Based on my past experiences, (almost) pure developers can't seem to forget physical details long enough to do a proper logical design. Any who could do it properly would be the rare exceptions, not the normal rule.


I agree it would be the exception but the "rules" as posted sounded like absolutes and I disagree with that sentiment.



Again, my exception is only for someone who had 1+ years full-time experience doing database design.

Almost every developer I've ever met believes they can properly design a db; 99.9% of them have no real clue about how to do it properly, however.

Ask them one thing, like:: Give a sample "supertype" with "subtypes" :: and they're completely lost.


SQL DBA,SQL Server MVP('07, '08, '09)
"In America, every man is innocent until proven broke!" Brant Parker
Post #1410299
Posted Tuesday, January 22, 2013 10:02 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 4:14 PM
Points: 13,126, Visits: 11,964
ScottPletcher (1/22/2013)
Sean Lange (1/22/2013)
ScottPletcher (1/22/2013)
Sean Lange (1/22/2013)
GilaMonster (1/22/2013)
Sean Lange (1/22/2013)
ScottPletcher (1/22/2013)
DiverKas (1/22/2013)
1) Do NOT let your C#/VB/ASP/Pascal guys design the database.
2) Do NOT let your DBA's design the database.
3) Hire a Data Architect.

Just saying. The first 2 groups have very biased views of how data should be structured for VERY different reasons, neither of which usually solves the entire problem.



#2 is NOT necessarily true -- it depends on the DBA. I have long-term experience in all phases of the design process.

Also, if you hire someone who's solely a Data Architect, then you have to hire an additional person to convert the logical model into a physical model.


Neither is #1. There is no rule that says a developer is unable to design a proper database because they are a developer.


I'm a developer (SQL mostly, not front end). I'd argue that I can design at least a passably good database.


Gail we are saying the same thing. I think anytime someone starts segregating abilities based on job title they are destined to get snowballed. I too am a developer and would like to think I could cobble something usable together.



Perhaps. But I would not want someone who had not been a full-time database designer or DBA at some point to head a db design. Based on my past experiences, (almost) pure developers can't seem to forget physical details long enough to do a proper logical design. Any who could do it properly would be the rare exceptions, not the normal rule.


I agree it would be the exception but the "rules" as posted sounded like absolutes and I disagree with that sentiment.



Again, my exception is only for someone who had 1+ years full-time experience doing database design.

Almost every developer I've ever met believes they can properly design a db; 99.9% of them have no real clue about how to do it properly, however.

Ask them one thing, like:: Give a sample "supertype" with "subtypes" :: and they're completely lost.


Sadly it is not simply because they don't understand data modeling. Those same people could not identify a super class and subclass example in OOP either. Let's face it, there are far too many totally incompetent people in this field.

By your definition I have no real clue about how to go about data modeling properly. I would disagree with you there. Am I the best? Absolutely not. But to simply discount my ability because it was not my primary job focus for at least a year comes across as arrogant and misguided. A person and the knowledge they possess go beyond the job title.




_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1410337
Posted Tuesday, January 22, 2013 11:28 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 10:07 PM
Points: 3,617, Visits: 5,236
Don't get me started!

I do however wish to hear the further discussion.



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1410355
Posted Wednesday, January 23, 2013 8:26 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 3:48 PM
Points: 1,973, Visits: 2,919
I think what's arrogant is for a developer to assume that they have the professional skills of another a DA/DBA job when they've never done. Not sure why everyone assumes they can do what a DA/DBA does even w/ NO job experience; rather interesting phenomenon really.

Are there exceptions? I'm sure there are. But you can't set up rules that handle the 0.1% of exceptions.

I was a developer for several years, including OO (went to some OO design classes too). But I wouldn't presume to claim I'm currently qualified to head up a development project, OO or not. Or even a code design project; although I believe I could provide valuable input on code design, I'm not qualified to lead the process.


SQL DBA,SQL Server MVP('07, '08, '09)
"In America, every man is innocent until proven broke!" Brant Parker
Post #1410616
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse