I am piping in here for the first time. I am new to this list so I don't
know the history of the database project. In particular, I don't know what
the purpose of the database will be. I also think that much of the
discussion could be conducted off the list since it is getting too
technical for most participants. I would like to be involved with the
project in some capacity, however.
I presume that the purpose is for people to record their roasting
experiences with different roasters and beans under different conditions.
We may also want to identify the method of grinding and the method of
preparation.
In design terms, we need to identify the major and minor entities and their
relationships and we need to "normalize" the data. But this is such a
simple task that it can all be done intuitively.
It seems to me that the major entities are "Person" and "Experience". The
minor entities are "Roaster", "Coffee", "Grinder" and "Preparation Method".
All other information would be attributes of these entities.
The attributes of a Person could include ID#, Name, Location, Experience
Level, Personal Comments. We can decide what we want to include and most of
it should be optional. The ID# should be a non-significant numeric and
would serve as the primary key.
The ID for Roaster would be a character string with a length of 6 or 10.
The main attribute would be a description. Other attributes may be applicable.
The same goes for Coffee, Grinder and Preparation Method. We could use a
meaningful abbreviation for the ID and a description of adequate length as
the main attribute.
The most important table is Experience. The whole database exists to
support this table. The attributes of Experience would include a numeric
ID#, Person ID, Coffee ID, Roaster ID, Grinder ID, Preparation Method ID.
All of these IDs would be accessible through pop-up lists. We will have to
determine how we let users add new items to these lists. The descriptions
associated with these IDs should be visible on the screen so that viewers
don't have to remember what the abbreviation stands for.
Unless we restrict choices of these attributes in this way the data will
quickly become a meaningless jumble. I realize that some may object to
these restrictions and some of the objections may be valid. As I mentioned
above, I am not yet clear about the purpose of the database and the design
should accomodate the purpose.
Other attributes of "Experience" would include pertinent roasting
information such as total time, time to first crack, time to second crack,
characteristics (such as acidity, body, etc.), bean temperature,
observations, results, etc. Most of this information should be optional.
We may want to institute a numeric grading system so that we can easily
produce a list of experiences in order by grade. "Grades" would be another
minor entity.
Regarding tools, comparisons to Napster are not really relevant. This will
be a very low-volume application. Napster gets hundreds of thousands of
hits continuously. I think that either
Access/FoxPro/ASP/Javascript/VBscript in an NT environment or
MySQL/PHP/Javascript in a Unix environment would be just fine. We don't
need Oracle or SQL Server.
Don Staricka
|