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

Database Design Checklist Expand / Collapse
Author
Message
Posted Thursday, July 16, 2009 6:20 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, May 10, 2011 12:15 PM
Points: 35, Visits: 210
can anyone give me the database design checklist to make sure the database design is proper?
like,
1. Have db design met the the requirement specification?
2. Is concentual Design created?
3. Is logical Design created?
4. Is Physical Design created?
5. Is Database normalized?
6. Are constraints defined?

please suggest me any other points are to be inserted?.


Thanks,
Ramani
Post #754078
Posted Thursday, July 16, 2009 7:44 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 3:26 AM
Points: 14,205, Visits: 28,536
I'd add a step to design the clustered indexes. They should be part of the fundamental decisions around the database design.

----------------------------------------------------
"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
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #754179
Posted Thursday, July 16, 2009 11:41 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, May 10, 2011 12:15 PM
Points: 35, Visits: 210
Thanks for the suggestion.

Grant, when constraints are defined, clustered index also will come (for primary key). or anything else apart from constraints, should that be defined?




Regards,
Ramani
Post #754627
Posted Friday, July 17, 2009 6:01 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 3:26 AM
Points: 14,205, Visits: 28,536
Well, the reason I'm suggesting you need to define the clustered index as a seperate step is because, it doesn't necessarily come from the primary key. Don't confuse the two because SQL Server defaults to making the primary key clustered. One doesn't automatically flow from the other. I like to examine the structures and make a conscience decision as to where I'll place the clustered index. More often than not, it's on the PK, but not always.

Since the data is stored with the clustered index, it makes sense to use the most common access path to the data as the cluster. In a lot of tables the most common access path is the PK. But in some tables it might be through foriegn keys, say a child table that is only accessed through joins to the parent, or by specific date ranges, who knows. Understanding the design such that you can determine these access paths up front should be standard part of the design, in my opinion anyway.


----------------------------------------------------
"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
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #754748
Posted Friday, July 17, 2009 7:21 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, May 10, 2011 12:15 PM
Points: 35, Visits: 210
Thanks a lot for this clarification Grant.

Now i understood y we need to include one more item for defining clustered index.


Regards,
Ramani
Post #754813
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse