Talk:Events Database

Quick and Dirty Roadmap

To echo Richard - writing the code will be the easy part. Making decisions about form, functionality and features will be much more difficult since they will take careful consideration and will evolve as the project nears completion. There are three code deliverables:

1. The web interface that the public will use to signup/request information/etc. This will require several web pages but will be the easiest to build because the options the user has will be relatively simple. It's important to get this done first because of the relative simplicity on the "front-end" of the front-end.(deciding what form it should take and what it should do).

2. A data-query tool to run reports, harvest contact info, add notes, etc. While this could be a web-app, it wouldn't be a pretty one. I envision a stand-alone GUI with A LOT of controls given the specs that have already been outlined. The query-tool will have two parts - the design of the interface and once that's decided, implementing functionality (hooking it up to the db).

3. The database. Designing the database will be much easier once the first objective and the design of the second objective are settled. There's a BIG difference between being easier and being easy though. The database will be the engine that drives the project and until the first two objectives are solidly defined, subject to constant tinkering. Knowing WHAT we want the DB is supposed to do will be the hardest part about about writing it.

I'll put together mock-ups of the first two items and distribute them to stakeholders sometime this week. My mock-ups are NOT to be considered work in progress or attempts to complete the project. In my experience as a coder I've learned that it's a lot easier for a group of people to share a common vision if they're looking at the same thing. Mock-ups are intended to get the conversation started. JTE--192.168.254.89 19:44, 22 Jan 2005 (PST)

Implementation Issues

The first step for this will be to outline all the needed screens and reports for this new module of the database.

Then we look over it all and figure out what tables need to be altered or added to support those screens and reports.

Then we write the SQL that can make that happen.

All of the above should not take too long or be too difficult, but should be well thought out. It all ends up making changes to the underlying data structures.

Finally, we need to write and test the code that talks to those data structures. Some of it is already in place (like the contact information), and some will need to be written from scratch. At this point, it's good to know what's most important, so we can prioritize the parts that need to be done first, adding the other stuff later on.

rfs 18:45, 22 Jan 2005 (PST)