[Tech] Re: Supporter database status

[Jamie O'Keefe]

> A possible solution might be to use this tool (CiviCRM) as a way to meet the
> needs for tracking supporters/volunteers and contributors.  Then we
> could build a separate voter database using another tool.

I am leaning toward this idea much more (as much because we need
something now and I don't want to reinvent what they have done).  the
voter db interface could end up using the same database as the
CiviCRM, and we could come up with code (sql or otherwise) to deal
with merging in updates from the voter records.  I need to look at it
further, but Django might be able to use the authentication tables
from CiviCRM which would solve one problem nicely.  Also, for any
features not in CiviCRM we could write code to do using their schema.

Open issues:

1.  Does it do what the contributor database does and if not, can we
write code to do what Dan needs the contributor db to do?

2.  What features are not in CiviCRM and can we write add-ins to
perform those functions?

3.  What is the schema for CiviCRM and how can we merge our data into it?

4.  Does it support access to the data on a town by town basis?

5.  What do we need in the voter schema, what features does the voter
lookup app need, how will we handle updates to the voter data from the
state, how will we link the voter data with the CiviCRM supporter
data, as well as under what cases will we merge new voter data into
the CiviCRM supporter data?

6.  There are 4 million+ voter records that the state has?  How can we
setup the database to store that data in memory efficiently and how
much memory will we need to do it?  John Eskew, might you be able to
answer this one?

Jamie