1) Random thoughts in no particular order. Many items are "for future use" 2) Use "person" table as we will have info on people who are not members. "member" table will use "person.id" to link. 3) Assuming DB is MySQL with engine able to support transactions. 4) Small application with low volumes, no need to be efficient. 5) ALL person information except email address to be encrypted. 6) Membership - objective is for members to manage their own info - cron task to email reminders when dues are payable. allow them to change personal info 7) SOMA has "family membership" where family is ambiguous. I interpret family to mean people living at the same physical address, and prefer the term "Household", so "HoH" (head of household" is primary member and responsible for payment and only "person" to have physical address. Additional household members have person.id field to identify the household to which they belong. 8) In order for persons to modify their info, they will use email address/password to log in. I would like two step authentication - log in sends email with link to actually get to account. ----- More later

9) Person "joining" SOMA must be HoH, and can add up to 9 members of the household. Since some may not yet have an email address, it is only a required field for HoH, and we will synthesize and email address where not entered e.g. [email protected] which will forward to the email address of HoH.

10)

10) Still to come - Notes table, Payments table