database architechture, saving admin users,site members,newsletter subscribers.what's the best practices

Question

am sure a lot of people may have asked this kind of question before, but i think there is a difference here. I have a web site using Zend Framework+ doctrine.I'm using zend_acl and custom zend_auth for doctrine.i've been using different table for admin users and another one for site members. I did so because there were too much field for site members and admin members do not need to fill that form.besides there are only few "nullable" field in members table I'm on the verge of adding newsletter feature and i was thinking, what if the business rule was to allow people to sign up without necessarily being members.

Where am i going to store them? create another table sound like bad design since maintenance can be an issue.

So here is my question.
Question 1 : is it a best practice to separate site admin and site members?
Question 2 : should newsletter subscribers be allowed to subscribe without being members of the site's community.if so how to handle that?

Thanks for reading.

Answer 1

RE Question 1: You can extend your pre-built site admin tables logically by adding your own independent tables that contain extra attributes that you need. Just use FKs to the PKs that are already in your pre-built site admin tables. This is a common practice for any system customization where you have a pre-built system that doesn't contain all of the columns or tables that you need.

RE Question 2: It depends on your site's purpose. If you are building a site for a business, a charity, a service organization or the like, then I would suggest that you want to allow as many people as possible to subscribe to your newsletter. If you are building a site for a secret society then you would be better to keep it locked down! This is a business rule decision, not a database design decision.

The technical design for this is to capture the e-mail (or snail mail - if that is how your newsletter is delivered) of the non-member subscribers. Then you build a view which performs a UNION ALL of your members and your non-member subscribers. This view will give you the list of all subscribers, regardless of what else you know about them and how they fit into your site.