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.
Norman's right, just normalize the database, like it should be. It's
the only way you'll be able to get decent reporting.
You can use a one-to-many relationship like Norman suggested or a
many to many with an intermediary table.
Google for relational databases and read about it, it's really worth
the time.
Best regards
Peter De Berdt
_______________________________________________
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>
