Have Geek Brain

Blog Data Model Tuning Guidelines

I have the following setup for my blog data model:

Blog Articles Categories
----- -------- 1 ----------
ID \ 1 * ID / ----- ID
Name \ ------------ BlogID / Name 
Owner Name * /      
                   CategoryID- /

I'm worried about how this data model fits in with "best practices" for blogs. If a blog is deleted, should all articles for that blog be deleted? If a category is deleted, what should happen to the articles?

Is there a better way? Is there something I am missing? What do "best practices" offer?

+1


a source to share


7 replies


It really depends on your use case. Many blog applications use many-to-many tags instead of one-to-many categories because it makes more sense to treat an article as referring to (possibly) many tags than viewing the article as being "contained" within a category.

If the logic behind your blog is that the article is strictly contained within a category, then a one-to-many relationship is justified. And in some cases, cascading deletion will also be warranted. After all, where would the orphaned articles exist.



This is just a case where you have to anticipate your user-based intuition. What they assume is natural.

By the way, this is a lot more work, but if it were me, I would not have done the cascading delete. I would mark articles as orphaned and hide them from most views. I would also provide some interface for recovering orphan articles. And I would consider providing a script that deletes whatever was lost for more than a specified period of time. That way, if you were wrong about what your users expected, you can fix the problem.

+3


a source


This (older) post contains some of the tagging-related db schema variations, including a detailed discussion. Maybe this is a good starting point.



+2


a source


Depends. If your blog engine does not allow posting without a specified category, you should probably notify the user of the consequences and remove the articles. Otherwise, you can use it instead ON DELETE SET NULL

.

+1


a source


If your relationship is set up correctly, you cannot delete a category without first deleting all related data. It seems odd that deleting a category would delete a bunch of articles, but at the same time, if the category is no longer valid, then the articles shouldn't be either.

Possibly an option to reassign all articles to a new category.

+1


a source


A few questions. Can an article have more than one category? Do you allow an article to have 0 categories associated with them? However, from your description, I would say that you do not want to delete articles. Categories, in my experience with blog design, usually have many, many relationships with articles / posts (multiple categories describing multiple posts). So I wouldn't delete them, but once again it would depend on your business logic and how you wanted to handle it.

+1


a source


Well, your foreign key (which must exist) associated with your blog category on your blog post won't let you. You should consider changing the category of your article to a different one if you want to preserve your article and referential integrity.

0


a source


Forget data model, use Object Model, this is that data is implementation and object is an interface that is closer to the requirement.

0


a source






More articles:


All Articles