[wplug-web] Re: Meeting DB

Jeremy Dinsel jeremy at gunix.net
Mon Jun 3 19:16:33 EDT 2002


On Mon, 3 Jun 2002 wplug-web-request at wplug.org wrote:

: Date: Sun, 2 Jun 2002 17:30:38 -0400
: To: wplug-web at wplug.org
: From: Zach Paine <zman at wplug.org>
: Subject: [wplug-web] Meeting DB
: Reply-To: wplug-web at wplug.org
:
: Hey,
: 	I want to re-organize the meeting DB.  Currently everything is
: 	kind of hapharzadly thrown into one table.  Someone decided
: 	along the way that we should keep track of each 'new' meeting
: 	info via an id, but this breaks down logistically somewhat
: 	because frequently, info will change for a meeting, but not an
: 	installfest.  Should this be a new record or a modification of
: 	an existing one.  Currently it seems that seperate records are
: 	determined by when the info changes or something.  I'd like to
: 	seperate the meeting info and installfest info into seperate
: 	tables, as well as create a new table for tutorial info.
: 	Obviously this would involve some re-write of the php, but
: 	nothing grand.  In the process, I would also like to further
: 	abstract some processes that are repeated over and over such as
: 	connecting to the DB and making certain calls.  How do you guys
: 	feel about all this?

It was I who gave the meetings a unique ID as we had been *deleting*
previous meetings with each new announcement. :( When information is
updated, the records should stay the same (minus the changes)--the
unique ID should be the key that is used when updating fields. Again,
the unique ID is set when a new entry is created -- it should never
change.

I guess I'm not really seeing what the problem is. Can you give an
example?

It does not make sense to me that we'd want seperate tables for the
different meeting types.

Please keep in mind that monkeybot relies on the tables to be accessed
as they currently are. Without this ability, monkeybot cannot get the
news or the meeting information.

-j




More information about the Wplug-web mailing list