﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / SQL Server 2005 / SQL Server 2005 General Discussion  / Database Design Checklist / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Wed, 22 May 2013 11:15:08 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Database Design Checklist</title><link>http://www.sqlservercentral.com/Forums/Topic754078-149-1.aspx</link><description>Thanks a lot for this clarification Grant.Now i understood y we need to include one more item for defining clustered index.Regards,Ramani</description><pubDate>Fri, 17 Jul 2009 07:21:56 GMT</pubDate><dc:creator>Chandhini</dc:creator></item><item><title>RE: Database Design Checklist</title><link>http://www.sqlservercentral.com/Forums/Topic754078-149-1.aspx</link><description>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.</description><pubDate>Fri, 17 Jul 2009 06:01:33 GMT</pubDate><dc:creator>Grant Fritchey</dc:creator></item><item><title>RE: Database Design Checklist</title><link>http://www.sqlservercentral.com/Forums/Topic754078-149-1.aspx</link><description>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</description><pubDate>Thu, 16 Jul 2009 23:41:14 GMT</pubDate><dc:creator>Chandhini</dc:creator></item><item><title>RE: Database Design Checklist</title><link>http://www.sqlservercentral.com/Forums/Topic754078-149-1.aspx</link><description>I'd add a step to design the clustered indexes. They should be part of the fundamental decisions around the database design.</description><pubDate>Thu, 16 Jul 2009 07:44:44 GMT</pubDate><dc:creator>Grant Fritchey</dc:creator></item><item><title>Database Design Checklist</title><link>http://www.sqlservercentral.com/Forums/Topic754078-149-1.aspx</link><description>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</description><pubDate>Thu, 16 Jul 2009 06:20:19 GMT</pubDate><dc:creator>Chandhini</dc:creator></item></channel></rss>