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

Design database for blog app Expand / Collapse
Author
Message
Posted Thursday, December 19, 2013 1:26 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, December 21, 2013 2:30 AM
Points: 1, Visits: 5
Hi folks!
Don't scold me for trivial questions about db design. I am newby in db design, and I need some advice about design tricks and features db. Please write me, what mistakes I did, what did I forgot, what did I broken etc.

p.s. Schema db design attached to the post.

****Schema db design
Post #1524777
Posted Friday, December 20, 2013 4:17 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 6:53 AM
Points: 13,890, Visits: 28,285
Seems OK to me. I'm not crazy about the pattern where you name each PK with the same name and then you have to figure out where it's used elsewhere. I'd rather see UserID for User & BlogCategoryID for BlogCategory, etc. It just makes things more clear and clarity is something to strive for. I don't see indications of unique constraints. You're using the "Identity Everywhere" approach to primary keys (and arguments can be made for both sides as to the utility of it), but you're still going to have to enforce unique constraints to prevent duplication of data.

For me, a table like BlogRelationPosts wouldn't have an identity. It serves no purpose. The other two columns would probably be the primary key. Same thing on any other many-to-many situation.

Basically, it looks relatively functional for how I would imagine a blog database to be put together if you were storing it relationally.


----------------------------------------------------
"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 #1524924
Posted Monday, December 23, 2013 1:58 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:51 AM
Points: 7,799, Visits: 9,547
I agree with Grant. In addition to what he said, the natural keys which have to be defined by UNIQUE constraints since your primary keys are all surrogates should have each column constrained NOT NULL.

Tom
Post #1525442
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse