As long as you have proper indexing setup on the table, there shouldn't
be an issue with querying it. You can also run a Trace on the table,
once it is use, to see if any additional indexes can be created, based
on the actual usage stats of the table
Dave
-----Original Message-----
From: Cohen, Michael [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2003 7:30 PM
To: CF-Talk
Subject: RE: Data Model Design question
Thanks guys! I was figuring close to a million records
potentially. I gather
from Jochem's question that a million is not "prohibitively
large?" :)
Even to be querying on all the time? And Dave's comment about
modifying
your db schema was interesting. I didn't know that. Any db
fundamentals book
recommendations? Thanks again.
-----Original Message-----
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
Sent: Mon 11/10/2003 6:57 PM
To: CF-Talk
Cc:
Subject: Re: Data Model Design question
Cohen, Michael wrote:
> Say you've got a COURSE table that represents many courses.
New courses
will
> always be being added to the table. Each course will have many
quizzes and
> questions that need to be stored. You would not want to have a
single QUIZ
> table with a composite key of COURSE_ID and QUIZ_ID because
potentially
this
> table would become prohibitively large, correct?
What is prohibitively large? 10 million? 100 million?
> Also, each quiz will have
> many questions, stored in a QUESTION table. This even more so
would become
> prohibitively large if you stored questions for every quiz in
every course
> in one table. Sooo, you would want a QUIZ table and QUESTION
table for
each
> course, correct?
No. Generally speaking, databases scale better in the number of
rows per table as in the number of tables per schema. One course
table, one quiz table, one question table.
Jochem
--
Who needs virtual reality
if you can just dream?
- Loesje
_____
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
