How many mySQL tables is too many? (While working with DBI)

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I'm working on a Perl project and it currently uses about 50 different tables. Should I attempt to consolidate and lose readability and organization, or is there no efficiency hit along the Perl->DBI->mySQL pipeline?

Comment on How many mySQL tables is too many? (While working with DBI)

Replies are listed 'Best First'.
Re: How many mySQL tables is too many? (While working with DBI) by screamingeagle (Curate) on Feb 13, 2002 at 18:13 UTC
well, not knowing the details of your database schema will certainly hinder my reply. However, the general appraoch for database design is to make it conform to the Third Normal Form (3NF) Here's are a few links to articles describing Data Normalization Database Normalization Basics First Normal Form Second Normal Form Third Normal Form hope this helps :-)	[reply]
Re: Re: How many mySQL tables is too many? (While working with DBI) by Anonymous Monk on Feb 13, 2002 at 19:12 UTC
Hi, I just wanted to take a moment and thank you for your reply. I read all of those links and they were extremely helpful. It will certainly assist me in my design. Thank you!	[reply]
Re: How many mySQL tables is too many? (While working with DBI) by perrin (Chancellor) on Feb 13, 2002 at 18:12 UTC
There's nothing inherently wrong with having a lot of tables. If you run into problems with joins being too slow, you could look into various forms of caching, including caching in a de-normalized table. Don't do that until you actually hit performance problems though.	[reply]


Just another Perl shrine
	PerlMonks