View source for Membership Database Schemas

{{learn edit}} <br>

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: [http://www.techsoup.org/learningcenter/databases/index.cfm Database section on techsoup.org]<br>

<br> 

;Name - First 
:<br>
;Name - Middle 
:<br>
;Name - Last 
:<br>
;Name - Salutation 
:<br>
;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.

<br> 

----

<br> 

;Address - Street 
:May be broken into multiple fields, or include a separate field for apartment #. 
;Address - City 
:<br>
;Address - State/Province 
:<br>
;Address - ZIP/postal code 
:<br>
;Phone 
:May have multiple values. May include option to indicate primary/work/home/mobile. 
;Email 
:May have multiple values. May include option to indicate primary/work/home/mobile. 
;Contact method preference 
:Postal mail, email, phone, sms, etc.

<br> 

----

<br> 

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

<br> 

<br> 

;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 &amp; attrition. 
;<br>
;Dues last paid 
:Useful for recurring investments or organizations with recurring dues 
;Dues amount 
:<br>
;Receipt or record number for dues transaction 
:<br>

<br> 

----

<br> 

;Training indicators 
:What areas of training have been completed. Including level of training or skill level can be problematic. 
;Committee or group memberships 
:<br>
;Schedule of availability 
:For startup work, project work, store operations work. 
;Work assignment 
:<br>
;"Status" 
: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.

<br> 

----

<br> 

;Skill list 
:See [[Schemas: Skill List]] 
;Indicator of shared shifts &amp; 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? 
:<br>

[[Category:Technology]]