Re: Table Sizes

In general, it would make sense to logically break them out as it makes sense with the related
data. A "catch-all" table throws away the very relational table concept so it obviously would make
sense to have related tables.

A table/db with 32 million records should be optimized. 

For example, I would think that there's a few fields in there that could be broken out into their
own tables by ID as well as other data.

The savings in speed and size would be very significant. To take a field that might be 20 bytes
and replace it with a 5 byte ID x 32,000,000 would be a huge savings in space for that one field
alone.

Greg
--- Bill Platt <[email protected]> wrote:

> I am wondering which is most effective.
> 
> Setting up a table with smaller pieces and
> writing the software to search smaller tables,
> OR
> setting up one big table with all of the related
> data inside of it?
> 
> I have a mysql database I am working with
> that has 32 million records in it. I am wondering
> if I would be better off to somehow break that
> data into much smaller pieces so that there are
> fewer rows, or whether it is just as effective to
> keep everything in one table.
> 
> Maybe I should break it down alphabetically
> or something.
> 
> The reason for my concern about this is when
> I access the database through phpMyadmin, every
> request takes  long time to load up. Even minor
> changes seem to be a real pain in the you know
> what.
> 
> Speed within the site is of vast importance to me.
> 
> Thanks for your advice.
> 
> Bill
> 
> 
> -- 
> MySQL Perl Mailing List
> For list archives: http://lists.mysql.com/perl
> To unsubscribe:    http://lists.mysql.com/[email protected]
> 
> 


-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/[email protected]