问题
Imagine a company that lets people use their web software to build web sites. Each customer has one or more sites that they've built and each of these sites will contain perhaps a hundred "cells" that hold the HTML for various pieces of the site. We know for certain that each cell will only be used in one site. So we have:
Now we need to describe the cells in each site.
One way would be to have a huge (and I mean huge) cell table that contains all the cells created by a million customers. Then each cell record would point back to the siteId where it was used.
But it seems that there should be a way to take advantage of the knowledge that each cell is only one of a hundred or so in its site, so instead of searching a table of 100 million cells we could search a table of 100 cells, or just ask for that table when we want to build that site.
Thanks for your input.
回答1:
One way would be to have a huge (and I mean huge) cell table that contains all the cells created by a million customers. Then in each row of a cell record we'd point back to the siteId where it was used.
This is probably the route I would go. Most modern databases can handle tables with hundreds of millions of rows when you use the proper performance tuning techniques.
I'm not positive but it sounds like you are considering placing cells for each site in a site specific table in an effort to keep the number of rows in each table down. If this is true it seems like you are trying to over optimize before you have any performance problems.
I would focus on creating a well designed normalized database at this point and if you run into performance problems, I would come back here with the specific performance problem.
来源：https://stackoverflow.com/questions/17374480/database-for-a-web-site-builder