Home > Archive > PHP Language > December 2004 > Do I make a lot of small Tables or a few big Tables?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Do I make a lot of small Tables or a few big Tables?
|
|
| mark1822@hotmail.com 2004-12-26, 8:55 am |
| Hello,
I am working on designing a Web site using PHP and MySQL and I am
currently figuring out how to best build my MySQL database.
My Web site is going to use a MySQL database extensively throughout the
Web site. It is a content management system type Web site with lots of
users and written articles and other things. With my database I'm
trying to figure out if I should create big tables that have a lot of
rows in them or if I should create a lot of tables that are very
specific to its data and use a lot of table joins in my select
statements. I'm mostly concerned about performance.
I'm thinking that if I make a lot of tables, then select statements I
do will be really fast because my tables won't contain very many rows.
But I don't know if this is true or not or if it matters for
performance reasons or not.
In my Web site I have a lot of different kinds of data that could put
in many different tables. But, without data redundancy and without
using extra storage space, I can still make a few big tables, and make
that work. I just don't know which way is best for performance --
speed, I want speed. Anybody know what I should do or know a book I
should read or a Web site to go to?
Much appreciated,
Nick
| |
| Colin McKinnon 2004-12-26, 8:55 am |
| mark1822@hotmail.com wrote:
>
> I'm thinking that if I make a lot of tables, then select statements I
> do will be really fast because my tables won't contain very many rows.
> But I don't know if this is true or not or if it matters for
> performance reasons or not.
>
Usually, costs are programmer time >> bandwidth > hardware.
So maintainability is at least as much of a priority as performance. Having
said that relational databases are all about storing and retrieving data
using a finite number of well defined structures. In other words:
1) Normalize your data
2) Aim for a few long tables rather than lots of short ones
3) fix perfomance issues in your physical design rather than logical
(there are cases where you need to address perfomance issues in your logical
design, but you really need to know what your doing)
HTH
C.
|
|
|
|
|