Peter Brown wrote:
> I want to be able to sort my customers via the products they buy. I know
> how
> to do an excel spreadsheet which is useful for mail merges. I also know
> that
> by adding new categories you can sort contacts. Which is the best
> system?
> Pros/cons of each method please
This is getting pretty database-ish. And it's getting to the point
where
it depends a lot on context. When you ask about "which is best" of
various possible designs, there are a few basic questions.
One is, which plan are you more confident of being able to finish
in the time alloted, on the software you are using, with realistic
size data sets? And which are you more confident will satisfy
the people who pay your salary? This is "what can Peter Brown
do?" not "what can the methods do?"
Another is, how well will you be able to keep up with requests
for changes in the future?
- Does each customer purchase the same set of products over
the entire history of your app? Never more nor less? Or do they
change rarely/frequently? Is there a maximum number? What if
some bright-light exceeds that number?
- How do you add a product? How delete it? How add a customer?
How delete?
- Do you ever want to search by products purchased this month?
This year? Last year? The last six months? Number of products?
Whether they bought a specific product? Net purchase in dollars?
- Are there any easily predictable other search parameters that might
be added in the near future? (Tax info, overdue payments, payments
due in the next month, etc.)
- When the boss sees how spiffy the app is, is she going to want to
make automated reports of various status information every week or
month or quarter or year? Once you've got one status report, will
she want another? (Status reports are the snack food of management.)
- What other easily predictable changes can you think of? Stick to
stuff that your client (users, the people who pay your salary) are
talking about wanting. How would you fit those in?
See if you can answer each of those and see how it would fit into
either of your possible implementations. If you can get the first
version of the app out on time, you look like a good coder. If you
can respond to change requests, get the new version out quickly,
and do it bug free, then you start to look like a coder demi-god.
Also, it may be you stick with Excel. But this *is* getting very
database-ish. You might consider whether it's time to move to
Access. Not necessarily, but possibly. Just keep it there on
the side of the desk until something shows you it is or is not
a reasonable move. For example, if you've already got a lot of
work invested in an Excel solution, it probably isn't a good idea
to leap to Access.
Socks
|
Similar Threads
