Re: Applications processed + future renewals
- From: Eric Baudais <baudais kkpsi org>
- To: Ghee Teo <Ghee Teo Sun COM>
- Cc: membership-committee gnome org
- Subject: Re: Applications processed + future renewals
- Date: Tue, 1 Jul 2003 12:59:25 -0500
On Tue, Jul 01, 2003 at 04:56:42PM +0100, Ghee Teo wrote:
Hi Eric.
It looks cool ;)
We definitely need a better system that the manual one at the
moment. Hopefully, the new system is not too heavy.
What did you use as the DB? How many tables have you defined?
Vincent's suggestion of 2 tables seem reasonable. We will need a field
for when the membership expires to send out reminder 2 months before hand.
If we want this to reside on the GNOME servers the database will have
to be MySQL. MySQL is the database installed and the system admins
won't admin two database servers. Currently the tables I have defined are:
+--------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+-------------+------+-----+---------+----------------+
| member_id | int(11) | | PRI | NULL | auto_increment |
| firstname | varchar(20) | | | | |
| lastname | varchar(20) | | | | |
| email | varchar(50) | | | | |
| contribution | text | YES | | NULL | |
| rel_date_id | int(11) | | | 0 | |
+--------------+-------------+------+-----+---------+----------------+
+----------+---------+------+-----+------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------+---------+------+-----+------------+----------------+
| date_id | int(11) | | PRI | NULL | auto_increment |
| received | date | | | 0000-00-00 | |
| accepted | date | | | 0000-00-00 | |
+----------+---------+------+-----+------------+----------------+
+-------------------+---------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+---------+------+-----+---------+----------------+
| relation_id | int(11) | | PRI | NULL | auto_increment |
| related_assign_id | int(11) | | | 0 | |
| related_member_id | int(11) | | | 0 | |
+-------------------+---------+------+-----+---------+----------------+
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+----------------+
| assign_id | int(11) | | PRI | NULL | auto_increment |
| assignee | varchar(12) | | | | |
+-----------+-------------+------+-----+---------+----------------+
+-------------------+---------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+---------+------+-----+---------+----------------+
| relation_id | int(11) | | PRI | NULL | auto_increment |
| related_result_id | int(11) | | | 0 | |
| related_member_id | int(11) | | | 0 | |
+-------------------+---------+------+-----+---------+----------------+
+-----------+------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+------------+------+-----+---------+----------------+
| result_id | int(11) | | PRI | NULL | auto_increment |
| result | varchar(7) | | | | |
+-----------+------------+------+-----+---------+----------------+
The suggestion of having a separate applications table depends on what
information is going to be entered in the table. If the application
table is supposed to contain the application from the web form then it
makes sense. However if the application table will just duplicate
most of the information in the member's table then it doesn't. You
would be duplicating the same information in two different tables.
Ultimately we could transfer the complete mailing list of
foundation-announce to here even ;)
What do you mean?
Eric Baudais
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]