Brainstorming part 2
Feb. 7th, 2008 02:57 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mikeknInstead of responding to each of the comments on my first post, I'm going to try and summarize and layout my current vision. I'm going to go into some implementation details, but none of these are set in stone, so comments are welcome.
A record in the event table will have the following fields:
- Event ID
Internal reference number - used to tie additional information to the event record.
- Event Name
- Date
- Location (city, state)
As published in Pikestaff
- Hosting Group
This will be a Group ID linking to my existing group table (currently only used for the newsletter inventory) That table will be expanded to include the parent group, founding date, dissolution date (if any) and other group information. (The group database is an other project altogether though)
- RP Info (if any)
Place for King, Queen, Prince and Princess. Link to court report(s)? (may be put in additional information)
- Event Announcement
Optional. Full event announcement (may be put in additional information)
A separate table will be set up for additional event information. Right now I'm envisioning at table with three fields:
- Event ID (what event is this for)
- Info Type (link-chronicle, link-photo, link-file, summary, announcement?, court report?, comment, ???)
- Info (text field containing whatever we need).
The type field will be used to help organize the event page (putting all the photo links together, etc). This set up allows us to have an unlimited number of additional bits of information, without leaving a ton of blank fields in most event records.
There will be an interface for people to add comments. I am currently leaning towards having people request an access code before being able to comment. The code will be used to authenticate them and tag their comment with their SCA name. That way I could have the comments get posted immediately. I'd probably still have each comment emailed to me so that I can watch of abuse, but I wouldn't need to approve everything. I want to start by having this as simple as possible (without opening it up to spammers), and add addition restrictions as they are needed.
There is some concern that people won't bother getting an access code, and so won't comment (points to near complete lack of response to requests for stories, artifacts and photos).
My one worry in all this is that I'll be creating another chirurgeon database. A nice system, very useful to the folks who wanted it (in that case, Hawk, in this case, me), but not used after they move on.
A record in the event table will have the following fields:
- Event ID
Internal reference number - used to tie additional information to the event record.
- Event Name
- Date
- Location (city, state)
As published in Pikestaff
- Hosting Group
This will be a Group ID linking to my existing group table (currently only used for the newsletter inventory) That table will be expanded to include the parent group, founding date, dissolution date (if any) and other group information. (The group database is an other project altogether though)
- RP Info (if any)
Place for King, Queen, Prince and Princess. Link to court report(s)? (may be put in additional information)
- Event Announcement
Optional. Full event announcement (may be put in additional information)
A separate table will be set up for additional event information. Right now I'm envisioning at table with three fields:
- Event ID (what event is this for)
- Info Type (link-chronicle, link-photo, link-file, summary, announcement?, court report?, comment, ???)
- Info (text field containing whatever we need).
The type field will be used to help organize the event page (putting all the photo links together, etc). This set up allows us to have an unlimited number of additional bits of information, without leaving a ton of blank fields in most event records.
There will be an interface for people to add comments. I am currently leaning towards having people request an access code before being able to comment. The code will be used to authenticate them and tag their comment with their SCA name. That way I could have the comments get posted immediately. I'd probably still have each comment emailed to me so that I can watch of abuse, but I wouldn't need to approve everything. I want to start by having this as simple as possible (without opening it up to spammers), and add addition restrictions as they are needed.
There is some concern that people won't bother getting an access code, and so won't comment (points to near complete lack of response to requests for stories, artifacts and photos).
My one worry in all this is that I'll be creating another chirurgeon database. A nice system, very useful to the folks who wanted it (in that case, Hawk, in this case, me), but not used after they move on.
