Is this how a modern news site would handle it's sql/business logic?

Question

Basically, the below image represents the components on the homepage of a site I'm working on, which will have news components all over the place. The sql snippets envision how I think they should work, I would really appreciate some business logic advice from people who've worked with news sites before though. Here's how I envision it:

Question #1: Does the sql logic make sense? Are there any caveats/flaws that you can see?

My schema would be something like:

articles:

article_id int unsigned not null primary key,
article_permalink varchar(100),
article_name varchar(100),
article_snippet text,
article_full text
article_type tinyint(3) default 1

I would store all articles ( main featured, sub-featured, the rest ) in one table, I would categorize them by a type column, which would correspond to a number in my news_types table ( for the example I used literal text as it's easier to understand ).

Question #1.1: Is it alright to rely on one table for different types of articles?

A news article can have 3 image types:

• 1x original image size, which would show up only on the article's permalink page
• 1x main featured image, which would show up on the homepage section #1
• 1x sub featured image, which would show up in the homepage section #2

For now I want each article to correspond to one image and not multiple. A user can post images for the article in the article_full TEXT column though.

Question #1.2: I'm not sure how I should incorporate the article images into my schema, is it common for a schema that relies on 2 tables like this?

article_image_links:

article_id article_image_id
1          1

article_images:

article_image_id article_image_url
1                media.site.com/articles/blah.jpg

Requirements for the data:

From the way I have my sql logic, there has to be some data in order for stuff to show up..

• there has to be at least one main type article
• there has to be at least four featured type articles which are below the main one

Question #1.3: Should I bother creating special cases for if data is missing? For example, if there's no main featured article, should I select the latest featured, or should I make it a requirement that someone always specify a main article?

Question #1.4: In the admin, when a user goes to post, by default I'll have a dropdown which specifies the article type, normal will be pre-selected and it will have the option for main and featured. So if a user at one point decides to change the article type, he/she can do that.

Question #1.5: The way my featured and main articles work is only by the latest date. If the user wants, for example, to specify an older article for whatever reason as the main article, should I create custom logic, or just tell them to update the article date so it's later than the latest?

Answer 1

In regard to the question in the title there is definitely more than one way to skin a cat. What's right for one site may not be right for another. Some things that could factor into your decision are how large the site needs to be scaled (eg are there going to be dozens of articles or millions?) and who will be entering the data (eg how much idiot-proofness do you need to build in). I'll try to answer the questions as best I can based on the information you gave.

Question # 1: Yes, looks fine to me. Be sure to set your indexes (I'd put indexes on [type,date] and [category,type,date]).

Question #1.1: Yes, I would say that is alright, in fact, I would say it is preferred. If I understand the question correctly (that this is as opposed to a table for each "type") then this sets you up better for adding new types in the future if you want to.

Question #1.2: If you only want one image for each story and one story for each image I'm not seeing the advantage of splitting that up into an extra table. It seems like it's just more overhead. But I could be missing something here.

Question #1.3: That's a design decision up to you, there's no "right" answer here. It all depends on your intended uses of the system.