[thelist] PHP/MSQL question millions or thousands

[Ken Schaefer]

As others have intimated, implementing 3rd normal form for your DB, and given decent hardware and programming, you'll be able to handle many millions of records.

Relational DBMSes heavily utilise set theory to accomplish what they do, and (generally) to get the best performance requires (a) you normalise your DB and (b) you effectively utilise SQL in your application.

For certain read-only databases (i.e. not OLTPs, but data warehouses) you may wish to break normalisation rules to optimise certain queries by reducing the number of joins, but generally you'd be talking many, many joins, or billions of records, before that becomes an issue on today's hardware.

Cheers
Ken

-----Original Message-----
From: thelist-bounces at lists.evolt.org [mailto:thelist-bounces at lists.evolt.org] On Behalf Of Fred D Yocum
Sent: Thursday, 7 February 2008 1:01 AM
To: thelist at lists.evolt.org
Subject: [thelist] PHP/MSQL question millions or thousands

I am planning a recipe MSQL database (for a Web site) and would like to be
able to search/extrapolate via single ingredients (list of all recipes
with carrots).

For those with experience, which is going to be more efficient -- creating
a separate entry for each ingredient (millions of little chunks of
information) or putting all of the ingredients into one entry and
searching within that entry (thousands of chunks of information that need
to be search in)?

TIA
Fred D