December 19, 2013 at 1:26 pm
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.:-)
December 20, 2013 at 4:17 am
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
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
December 23, 2013 at 1:58 am
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
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply