> composite key of COURSE_ID and QUIZ_ID because potentially
> this table would become prohibitively large, correct?
While it might become large - very large, even - I don't think it would
become prohibitively large. The same is true for your QUESTION table, for
that matter. We've done quite a few survey and HR applications that store
many, many records of the same sort - questions, groups of questions,
answers, etc. These applications have worked well enough despite the number
of records.
> Sooo, you would want a QUIZ table and QUESTION table for
> each course, correct?
No, I wouldn't. Whenever you find yourself modifying your database schema
during the running of your application due to new data being added, that
should be a giant red flag signalling to you the potential inadequacy of
your schema. Of course, there are exceptions to everything, but for the most
part, a well-designed schema should be able to manage any data generated
during the normal operation of your application without modification.
> That's easy enough if you just, say, appended the COURSE_ID
> to the end of the QUIZ or QUESTION table, but you run into
> a problem if you want all database access to be through
> stored procedures, as I don't know of a way to use dynamic
> table names in stored procedures with SQL Server.
You can always execute strings within your stored procedures using EXEC or
sp_executesql, but in general, this doesn't help performance any and should
be avoided when possible, I think.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
