The members_ table stores information about every list member on the server. Members are organized by list, and the same member may be on multiple lists. In this case there will be multiple rows in the members_ table for a single email address, one for each list that the member has subscribed to.
Internet standards are that the email address should preserve the case of the name, but not make a distinction for comparisons. To support this, and to make searching for members fast, the email address is represented twice in the table: once in full case-sensitive form (the EmailAddr_ column), and broken into case-insensitive pieces into columns UserNameLC_ and Domain_. ListManager will automatically populate these column when a new member is added, but if you want to add members to this table directly using SQL you MUST populate all the fields with the correct values. UserNameLC_ and Domain_ should hold the lower-case version of the portions of the email address, while the full case-sensitive version is stored in EmailAddr_. UserNameLC_ should hold the "user name" portion of the email address, i.e., everything to the left of the @ sign. Everything to the right of the @ sign should be stored in the Domain_ column. Neither the UserNameLC_ or the Domain_ should contain an @.
Information about the state of the user (such as on-hold or unsubscribed) is stored in the members_ table. This information allows ListManager to automatically handle administrative tasks such as putting user on hold, taking them off hold, purging users, requiring approvals before joining, etc. Many of the exact options for these are set in the lists_table.
Note that failed send attempts are recorded in the lyrCompletedRecips table: a total of the number of bounces for an address is no longer contained in the members_ table.
The members_ table has two fields that are not populated by ListManager, and are available for you to put any data desired. These are UserID_ for up to 20 characters of text, and Additional_ for unlimited text. Additional columns may be added to the table as long as the columns allow NULL or have default values. Adding columns that are NOT NULL will stop ListManager from being able to add new members, so is not recommended. Additional fields in the members table is an easy way to add information that is available for mail merging. However, it is also easy to create an SQL join to other tables, so that is generally a more flexible and efficient way to make your data available for mail merging. You should be careful about adding too many columns to the members table because as the table grows "wider" it will become slower and slower to get information from it, which will impact ListManager's ability to send mail quickly.
Primary key: MemberID_
Unique index: Domain_, UserNameLC_, List_
New index as of ListManager 9.1: IX_members_MemberType, index on (Lists_,MemberType_,DateJoined_)