On Jul 28, 2006, at 11:13 AM, GAmoore at aol dot com wrote:
Thanks Norman. Actually this whole scenario is vastly simplified
for the sake
of discussion. Essentially, they would want to keep each catalog
for each
season, then create new ones for the following year using the past
year's file as
a template. Over time there might be a dozen or more catalogs which
would
need to be kept separate but usually they would only be working on
one at a time.
I am thinking to just duplicate the customer and item info in each
file and
have each file self-contained - but it seems more efficient to have
different
tables in a big database in some way.
It may seem that way but the first time someone says "I wonder how
many times this item has been in a catalog" or "Which catalogs has
this item been in" you have a problem trying to answer it and it only
gets worse as you add more and more tables.
I could easily see needing to answer the question "How many years has
this person received catalogs from us"
With everything in separate files that is much harder to answer.
A normalized database design is your friend in many respects.
If you think you need several tables that are the same that's a bad
sign and an opportunity to rethink the design and coalesce them into
a table that you can still distinguish items from each other but can
do queries that cross years, catalos, etc.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|