HomeRoast Digest


Topic: database of info (29 msgs / 467 lines)
1) From: Chris Schaefer
Gang,
	I'm in a graduate level IT management class; we've been covering, very briefly, the topic of databases.  I've been thinking about what we could do, as an on-line specialty community (my phrase), to perpuate an on-line and easily accessible pool of information with repect to particular homeroasting data.
Here's what I've been envisioning; it is in need of serious refinement:
	An on-line database (and warehouse?), free at cost save the website that hosts it slapping banner ads everywhere, broken into tables and using relationships.  It would be accessible via user ID and password, and would contain data that we could update.
As for what data I had in mind: our roast results given particular machines, beans, conditions, etc.
	I think, by observation, that there is enough of us in this specialty community that log an assortment of data already.  Yes, a database of this nature my be incomplete and even messy, dare I say.  I see, however, that the potential benefits far outweigh the costs.
	I don't kow if there is a free db hosting service out there.  I certainly don't expect Thom and even our own community to build, support, and maintain such a creature.  So I am asking you (yes, YOU), if you know of such a service already in existence.
I look forward to the discussion of this topic.
Peace,
Gonzo

2) From: Jeffrey Vandegrift
Great idea! For this to work we need to agree on a
schema for the data, as well as what plug-ins would
be needed to access it. Have you delved into this
level of detail yet (the plug-ins obviously depend
on what server package would be used)?
I'm looking into "dynamic content" technologies for my
company, mostly at the large enterprise level, but I
may find something that's applicable on a smaller scale
and will post here if and when I find it.
I'm no DB expert, we usually outsource when there's a
DB component to one of our networking solutions (the
simpler or demo ones we can do ourselves). There's
potentially a lot of work involved.
Maybe a non-database approach would reduce the work but
still offer a way of posting and browsing for eachother's
free from data?
- Jeff
Chris Schaefer wrote:
<Snip>
-- 
Jeffrey Vandegrift, Principal Software Engineer
Trilogy Inc, 1732 Main St, Ste 101, Concord MA 01742-3810
Voice: 978.371.3980 x104    Fax: 978.371.3990
Email: jvande  Web:http://www.tril-inc.com

3) From: Byron Siegel
 
At 09:13 AM 4/10/00 -0500, Chris Schaefer wrote:
<Snip>
<Snip>
Chris,
     This idea seems to be a natural extension of what Mark has done on his 
consumer review site.
-- Byron

4) From: Chris Schaefer
That's what I was thinking.
----------
From: 	Jeffrey Vandegrift[SMTP:jvande]
Sent: 	Monday, April 10, 2000 10:34 AM
To: 	homeroast
Subject: 	Re: + database of info
Maybe a non-database approach would reduce the work but
still offer a way of posting and browsing for eachother's
free from data?
- Jeff

5) From: Chris Schaefer
Yes, it does.  In addition, I thought a relational database would be nice be casue a user, once logged in, could query data so they desire.  For example, suppose user X logs in and wants to download/display roast profiles for a particular bean depsite what machine was used.  it would involve a data base with the following:
a table for user info (which we've kinda created via the roaster roster), a table for beans, machines, roast style, and times.  And that should do it.  the user could query a particular bean, a desired roast style and a form would output the users who have contributed said data.
I'm not talking full GUI output per se.  Yes, the portal would be GUI- some java pp for example.  But I'm not talking about generating curves and graphs.  i think, fo rnow, just plain-text lists would be fine.
-Chris
----------
From: 	Byron Siegel[SMTP:byron]
Sent: 	Monday, April 10, 2000 10:34 AM
To: 	homeroast
Cc: 	Mark
Subject: 	Re: + database of info
At 09:13 AM 4/10/00 -0500, Chris Schaefer wrote:
<Snip>
<Snip>
Chris,
     This idea seems to be a natural extension of what Mark has done on his 
consumer review site.
-- Byron

6) From: Michael Allen Smith
<Snip>
don't expect Thom and even our own
I don't think this point has be touched.  There are quite a few free hosting
services, but none that I'm aware of that suport databases.  When it comes
to databases, you get what you pay for.  The cheapest server-side account
that allows non-ODBC connections to an Access database that I know of is
$15/month.  If this project requires a real database (Oracle or SQL Server)
then expect to pay $50/month or more.
Whatever happened to the Roaster Roaster project?  Me thinks there is
relationship,
mas

7) From: Christopher Schmelzer
I don't think plug-ins on any sort should be necessary... On the Apple
side of the OS world you can simply setup a relational database in
Filemaker Pro that can be accessed via CGI forms on the web...Easy as
that.  
I recently got a new DSL connection that allows personal servers and I am
currently working on acquiring an older Power Macintosh (7100, 7200, 7500,
etc..) that someone is hopefully on the verge of trashing or giving away
to be used as a server off my connection.  I would then run local web and
email services on it and could likely setup a relational database for
gonzo's idea on that same machine.
Anybody have an old PowerPC mac they want to get rid of?

8) From: Michael Allen Smith
If you go NT and go cheap, then Access is the solution.  Of course MySQL is
the best low-end database for UNIX.  And FileMaker Pro for the Mac.  With a
limited user base, any of those will work fine.  Pick your platform then
pick your database.  The point of my 4/10 post was that real databases like
Oracle, SQL Server, or Sybase don't come cheap.
mas
<Snip>
certainly
<Snip>
hosting
<Snip>
comes
<Snip>
account
<Snip>
Server)
<Snip>

9) From: Mark
 
At 09:57 PM 4/29/00 -0400, you wrote:
<Snip>
$20 a month, Apache, MySQL server access at superwebhost.com flat rate.
This is by no means the only one. But they operate as hands off as possible 
(ie, as long as you ain't tying up the pipe or bringing the system down, 
they don't care what you run).
Mark

10) From: Mark
 
At 11:11 PM 4/29/00 -0400, you wrote:
<Snip>
Access (esp. Access 2K) presents its own problems, esp. with a 
visitor-intensive site.
Mark

11) From: Michael Allen Smith
<Snip>
As does MySQL.  Napster dumped mySQL for Oracle, because of poor
performance.  Like I stated before, you get what you pay for.  For this
forum, Access or FileMakerPro or mySQL or FoxPro is more than sufficient.
mas

12) From: Mark
 
At 10:26 PM 4/30/00 -0400, you wrote:
<Snip>
Heh, by the time you get up to Napster's traffic levels, of course even 
mySQL is gonna be inadequate. So is the hardware and most pipes.
But trust me :-) , mySQL is perfectly fine unless you're moving millions of 
requests a day. Access 2K is not. I've experienced it firsthand, which is 
why we don't do Access 2K DB work any longer, AND the review component at 
Coffeekid.com is being converted to php and mySQL for the upcoming version 2.
Mark

13) From: Daniel Ho
For what we're looking for, I'm thinking that it can be implemented in MySQL
(free) but just need to find server space.  I can come up with the coding
and design required...it is what we do.
What we should be focusing on is a final list of features that the group
would like to see and see what we can do quickly and easily (yeah, if that's
possible)
Input?
d.
on 00/4/29 23:11, Michael Allen Smith at mas wrote:
<Snip>

14) From: Daniel Ho
I've used pair.com with good success.  I think it is something like
$29/month.
d.
on 00/4/30 21:46, Mark at spiffey wrote:
<Snip>

15) From: Chris Schaefer
Chris Schmelzer has a dedicated machine, a line, and the software already to go.  At no cost other than us developing the fields and tables needed.  (non-monetary)
I propose fields for user id, type of roasting device, particular bean, desired roast/agtron number, time of cracks, batch size, and roast temps.
CAS
----------
From: 	Daniel Ho[SMTP:hod]
Sent: 	Monday, May 01, 2000 3:07 PM
To: 	homeroast
Subject: 	Re: + database of info
For what we're looking for, I'm thinking that it can be implemented in MySQL
(free) but just need to find server space.  I can come up with the coding
and design required...it is what we do.
What we should be focusing on is a final list of features that the group
would like to see and see what we can do quickly and easily (yeah, if that's
possible)
Input?
d.
on 00/4/29 23:11, Michael Allen Smith at mas wrote:
<Snip>

16) From: Robert Cantor
ambient temp (room temp can be estimated) and machine setting will also be useful.
Bob C.
rcantor

17) From: Daniel Ho
What kind of box and what software?
I think that we should develop a Roaster Roster first that captures a
personal profile with basic personal/demographic info and some basic
roasting and brewing info.  People should be able to decide whether their
e-mail/addresses/phone numbers etc will be shown to everyone (there are some
that are concerned about privacy and spamming--personally, I'm not)
Here's the first cut of fields.  Please comment.
User Fields:
- user id
- date of record creation/when joined
- share personal information?
- first name
- last name
- address 1
- address 2
- city
- state/prov
- postal code
- phone #
- fax #
- e-mail address
- number of years of roasting
- preferred roasting method
- other roasting methods
- comments
Then, we build a database of user specific roast logs that are shared with
other users of the system.  I'm thinking that this should have basic search
facilities...so that you can type in Sumatra and see what others (who are
sharing their logs) have done.
Roasting Log Fields:
- user id 
- type of roasting device (need the possible choices here...)
- bean type (text field)
- desired roast/agtron number (text box)
- batch size
- roasting temp
- time of 1st crack
- time of 2nd crack
- duration of roast
- tasting notes (text)
Comments?
d.
on 00/5/1 16:46, Chris Schaefer at cschaefer wrote:
<Snip>

18) From: Chris Schmelzer
 
<Snip>
I'm pretty much opposed to any collection of personal information in 
this database, I can see choosing whether your email is displayed and 
maybe city, but not street address or phone numbers...
But I like the rest of your suggestion...
-- 
Chris Schmelzer, M-3
Medical College of Wisconsin
Milwaukee, WI USA

19) From: Daniel Ho
Why is that?  In the previous manual version, I think we had some personal
info + profession etc.  To me, if someone wants to fill out the info, the
profile is interesting and makes getting to know your fellow roaster easier.
Anyone else have thoughts on this?
d.
on 00/5/1 19:14, Chris Schmelzer at chriss wrote:
<Snip>

20) From: Chris Schmelzer
 
<Snip>
Privacy for one, avoiding spammers #2....Personal info like overall 
city and profession is fine by me, but specific contact information, 
especially that which goes beyond the electronic (email or web 
address) makes the database look more like a marketing database than 
a database of roasting logs...
-- 
Chris Schmelzer, M-3
Medical College of Wisconsin
Milwaukee, WI USA

21) From: Anthony Ottman
We're talking about two different things here, namely: 1) the roster of who
we are and 2) a log of individual roasts we've made.  From the sound of some
posts, there's a perception that these two may be merged into one big
database.  Merging all this is a design issue, maybe our database gurus can
give advice on whether that would be a bigger headache than it's worth.  It
sounds like a big job.
Regarding the content of the roster, I am comfortable with the information
in the original roaster roster.  Name, city of residence, roasting
experience, and preferred roasting and brewing methods are all appropriate,
and I find age interesting yet harmless.  For this group, which is not
directly exposed to the Internet, I don't mind posting my e-mail address or
real name.  In internet-based forums, I'd not be so open.  So far, I've been
spam-free from this group since joining about two years ago.  Kudos and
thanks to Tom for keeping it so.
- Anthony O.

22) From: Chris Schaefer
I prescribe to Schmelzer's view: the two should be kept wholly separate.  It's fine if there exists redundant information between the two... that's the nature of it.  But the Roster is for use with this mailign list.  The db is a resource tool, again for the members of this list, not to be confused with simply a "community builder" on its own.
Gonzo

23) From: Michael Vanecek
Er, poor performance is clearly relative here. MySQL is a fine database
server for all but the most excruciating tasks - and knowing the traffic
Napster was getting, it's no wonder they changed to Oracle. MySQL's
extremely quick and way more than the needs of this list. "You get what
you pay for" is kind of an interesting statement in this day and age.
Apache runs more than 57 percent of the world's Internet and it's free.
The entire Internet, barring the stunts M$ is trying to pull, is based
on Open Standards. Netscape and even IE are free (okay, I admit neither
browser is very good but that's because both companies got into a war
against each other and forgot about the costumer's needs). Linux is
free, as is FreeBSD. Both are very powerful operating systems that have
proven themselves time and again in a variety of environments. Memory
used to be $50 bucks a meg, now it's < $1 buck a meg. I don't mind
paying for software, but I'd never consider that Open Source or free
software is inferior in any way. If Tom doesn't want to be stuck to some
proprietory app like Access or FileMakerPro, then MySQL or PostgreSQL
are perfectly applicable choices.
Mike
Michael Allen Smith wrote:
<Snip>

24) From: Michael Allen Smith
This really isn't the forum for DB chat, but for the record all MS Office
file formats are open.  Any developer that wishes to create their own Access
or Word is free to do so and have compatibility work.  MS makes this
information available to anyone that wants it.
And to address another post about Access performance.  The rule is 10-10000.
If your tables have greater than 10,000 records or you expect more than 10
concurrent users, then Access isn't enough.  Anything less than that and
Access is fine.  Draw your own conclusions about this project.
mas
<Snip>
sufficient.
<Snip>

25) From: Daniel Ho
That was my intention all along.  But, the same user info/profile can be
used for both.  Why not?  Why type your profile and equipment used etc.
twice.
Or am I missing something?  I just came back from a longish trip and am a
bit fuzzy!
d.
on 00/5/2 08:49, Chris Schaefer at cschaefer wrote:
<Snip>

26) From: Daniel Ho
I wholeheartedly agree.  We have developed and run quite large sites using
unix/apache/php/MySQL.  I won't even touch Access anymore.  We have seen
similar code run one way on one machine, and completely differently on
another...really freaky stuff.  I wouldn't trust it to anything more than
local church mailing list...
MySQL is rock solid if not a real RDBMS.  If you need transactions, you need
Oracle/DB2/etc.  Otherwise, MySQL is fine for things that are mostly flat
files.  REALLY fast too!
on 00/5/1 02:14, Mark at spiffey wrote:
<Snip>

27) From: Daniel Ho
Also great and is OpenSource now is AOLServer.  Fast, good integration
inline with databases and did I say FAST?
on 00/5/2 21:24, Michael Vanecek at mike wrote:
<Snip>

28) From: peggykozy
I have a technophobe question about this data base...
How accessible will it be?  Will we all have to be on the same software
page or able to access the information from any server/software
package?  Are the software packages everyone is talking about the
"server" issues and not the user issues?
Don't want to seem ignorant - only uninformed.

29) From: Chris Schmelzer
 
<Snip>
User issues aren't really relevent as the database will have web 
based access for the end user, so any modern web browser will allow 
access
-- 
Chris Schmelzer, M-3
Medical College of Wisconsin
Milwaukee, WI USA


HomeRoast Digest