GOS, thanks for the links. I had come across those but I still could not get the action I needed from it. Granted, I am only an intermediate at this and still learning. In my situation, after thinking through the process and what was needed, I ended up determining that utilizing the Private Member Database (PMD) was actually not a beneficial solution for my needs.
For those asking…
In our case, we had a detailed membership roster that we needed to display internally to members only but then we needed to display certain members for any public visitor to see because they were leaders within the organization and those displayed had to be easily modified when the filled position was changed with a new member each year without editing every public page manually.
Two of the main issues I came across with using the PMD was: 1) only actual members who were signed in could see the pictures and info while visitors could not in the public spaces of the website. 2) Only a small number of our members were going to the website to register and upload their information so there was not a significant amount of listings. In addition to this, our leaders (who would not have dashboard / back-end access) needed to have a way to update certain information for each member along with updating a photo of them manually when needed.
So for my solution, I ended up creating 2 databases for members. The 1st database consisted of importing data from our main membership CSV file that we get from the corporate side of things. I used our member ID as the actual _ID key within the database collection since they are unique. This imported data would just override any information previously listed in the collection because of a variety of changes that could occur from the corp end.
The 2nd database created was for the “additional member data” which consisted of the picture, leadership positions, and some other pieces of changeable info. For this one, I only imported 3 pieces of info from the original CSV file (I have an excel macro tool that I created to help separate and export the info in the format needed) but unlike the 1st one, this imports by only copying new members based on their _ID key and not overriding the original data.
I have a member update form on the front end that Leaders have access to where they can go in and update the info needed in the 2nd database. With this done, the member ID / ID key in both databases allow me to link them to together easily when needed to pull info out to display in both the members only pages and also the public view pages.