Membership Database Schemas

From Cultivate.Coop

NEW! Cultivate.Coop is now just as easy to edit as Word and Google docs. Simply log-in, click “edit” on an article or resource page, and start contributing! See our explanation here.

As startups grow, and begin to publish newsletters, offer programs like CSAs and buying clubs, they will find themselves in need of membership management solutions. Whether they choose to make do with spreadsheets, or use database driven solutions, schemas will need to be determined. It's often difficult for a startup to predict what information will be needed in their membership records. Needs will vary between organizations, but this list is intended to make it easier for a group to assemble their own requirements list.

See also: Database section on

Name - First

Name - Middle

Name - Last

Name - Salutation

Name - Nickname or "short name"
Helpful for identifying duplicate names, allowing for privacy in some situations. Using these on documents like schedules, and on forums or discussion lists can foster group connections when people do not go by their given name.

Address - Street
May be broken into multiple fields, or include a separate field for apartment #.
Address - City

Address - State/Province

Address - ZIP/postal code

May have multiple values. May include option to indicate primary/work/home/mobile.
May have multiple values. May include option to indicate primary/work/home/mobile.
Contact method preference
Postal mail, email, phone, sms, etc.

Date joined
Can have varying interpretations depending on organization, but there should be a strong definition.

Date left
Date which member left organization. Depending on organization structure, this can mean a lot of things.
Reason for leaving.
Being able to note reasons for leaving along with member data allows for better analysis of member turnover & attrition.

Dues last paid
Useful for recurring investments or organizations with recurring dues
Dues amount

Receipt or record number for dues transaction

Training indicators
What areas of training have been completed. Including level of training or skill level can be problematic.
Committee or group memberships

Schedule of availability
For startup work, project work, store operations work.
Work assignment

This can be a troublesome area. Status terms must be clearly defined, and the conditions for moving between states need to be well established, or you may end up with status entries that don't actually mean anything.
On leave till
If there's an indicator of "on-leave" status, there should be a corresponding date for a future check-in. Without this, your database can be populated by on-leave zombies.

Skill list
See Schemas: Skill List
Indicator of shared shifts & relationships (spouses, housemates, etc.)
Either dynamically connected by software, or a simple text field for manual notation.
Key tracking
Who has keys to what.
Flexible "flags"
In database driven solutions, leaving some flexibility in the form of flags can be useful. If at some point in the future, your organization begins a pledge campaign, or decides to check the currency of some member information - having a simple checkbox that can be temporarily used for any purpose can provide a small amount of "future proofing." If your database is easily configured, this may not be necessary.
How did this person hear about the organization?