Database design for millions of posts

database-designdatabase-recommendation

I have this issue. I have three types of posts a user can generate (some users can generate all some can only generate one type). I have the following types: main, employee and admin posts.

I expect to have to deal with millions of posts (all three types). But about 90% of all posts would be main_posts. Also, most reads from the DB would be of the main_posts too.

NOTE
The main_posts table would have about 50-100 more fields than what is currently there. update
those fields would be normalized into different tables. The ideea is that the main-posts table would have the bulk of the posts and therefore would have the most reads and writes.

Which design option is more sound?

Option1
Option 1

or Option 2

Thank you.

Best Answer

Read this post how StackExchange does it:

http://www.brentozar.com/archive/2014/01/how-to-query-the-stackexchange-databases/

Related Solutions

Database design advice

                                                  +------------ --- ---+
                                                  | Assembly options   |
+------------+------------+----------+------------+---+---+---+ --- +--+
| assembly ▼ | unit cost  | quantity | total cost | 1 | 2 | 3 |     |50|
+------------+------------+----------+------------+---+---+---+ --- +--+
| VSD55      | £10'000    | 2        | £20'000    | 1 | 1 |   |     |  |

If somebody handed that quote to me, my first question would be "What's option 1 for the VSD55?" The answer would be "I don't know." That information isn't on the quote. In the unlikely event that person got to field a second question, that question would be "What does it cost?" Again, the answer would be "I don't know." A very disturbing silence would follow immediately, during which the person who handed me the quote would imagine how much better it might feel to be run over by a train.

Options must be line items on the quote, along with their unit price, quantity, and total price. Options must be named, not numbered. They should appear directly under their parent assembly, too, not scattered all over hell and half of Georgia.

If you want a shot at my money, you'd better make it crystal clear what I'm supposed to be getting for my money.

There's nothing (much) wrong with 50 check boxes on a user-interface form. That makes it easy to pick options. But the UI code should read the checkboxes and insert the right information into normalized tables.

Database Design – Creating Separate Tables for Different Product Types

If this were my design decision, I would probably go with more of an 'Option C' (modified option a).

First, why not 'Option B':

For one thing, I like the clarity that each product has it's own table affords. If it's all one big table with a field to determine the type, the relation isn't as clear.

For another, the indexing strategy would always require that type field to be listed. Since it's only 4 types, the index cardinality is extremely low (SELECT * FROM product_table WHERE type='X' is basically doing a full table scan anyway)

Option C

Create a parent table that holds only the columns that all types share
Create each product type as it's own table with their individual columns, with one extra: A link to the parent table
Create each 'link' table: Product_Option, Model_option, etc with links to the respective keys.
For those with reciprocal links (MODEL_OPTION, OPTION_MODEL) go ahead and create those tables as well. This will add clarity in your joins for anyone looking at it.

The downside is the complexity of making sure to avoid orphans when things are updated/deleted, and initially designing the queries that use these tables.