newsletter subscribers and customers table, same one or separate ones?

searain

I am building up an e-commerce site.

I am debating on this issue.

The site database would have a table to hold the customers information. Also the site database would have a table to hold the newsletter subscribers information.

For customer information, we need name, address, e-mail, password, shipping address (if different) etc.

For the newsletter subscribers, we only need e-mail and name.

I have been using two approaches before.

Approach 1: newsletter subscribers and customers are in two different tables. Same person will have to register with the newsletter subscribers or customers twice, if they want to be in both. of course, when he register for customer, we have a flag to ask if he want to register for newsletter too. it will register him for newsletter too if he check "yes".

The disadvantage is one user may have two accounts with the same site, one for customer, one for newsletter subscribers.

Approach 2: in the backend database, customers and newsletter subscribers in one table. some users could be only as customers, some only as newsletter subscribers and some as both.

Advantage is one user will only have one account for the same web site. The disadvantage is that in the programming, it add confustion, we have to tell, is this user already in our database yet? as customer, as newsletter subscribers, as both? For example, when a newsletter subscribers try to register to be a customer, we have to inform him, ok, you (or your e-mail address) already register with us as a newsletter subscibers now, so all you need is add some other fields for the address, password information etc., and we will update you to the customer account status etc. It is confusing for the user too.

I prefer to use approach 1. separte the customer and newsletter subscribers in two groups (two tables). Deal with them differently as different accounts even for a same user (e-mail address). In some cases, we may kill two birds with one stone, for example, if a user register for the customer account, and check the e-mail checkbox, he will be resiger for the newsletter subscribers too at the same time (but he will have two separate accounts, one for newsletter subscribers one for customer.)

What is your way?

Thanks!

Elizabeth

We have all in one table; a table of those registered at the site. Those are considered "customers" even if they have never purchased anything. Then there is a separate field for whether or not they are subscribed to the newsletter.

searain

Elizabeth wrote:
We have all in one table; a table of those registered at the site. Those are considered "customers" even if they have never purchased anything. Then there is a separate field for whether or not they are subscribed to the newsletter.

Yes.

But we want to make the newsletter subscribers registration to be easy and simple. Instead of they have to give the name, address, e-mail, password etc. to register as customer. we only need the newsletter subscribers to offer the name/email or just email to register for the newseltter.

In some sites, the newsletter subscribers pool is larger than the customers. Such as martial arts site which sell martial arts clothes, weapons etc., it also promote the events, the competitions, the class, the seminars etc.

These newsletter subscribers may not be the customers now. But we want to attact them to the site, so later on, someday some of them will buy and become customers.

leatherback

Sp, in your signup, you check whether it is a newletter signup, or a current client signup.
It is not a problem if YOU do the work. But make is easy for your customer. So if he only needs to add his postal detail;s when he orders, and his email / name are already pre-filled out, athat save the customer effort, and he/she will like the design. However, if he needs to give his email again he will be like "What the *, I signed up for the newletter. They know all this already!"
I tend to hang towards one table "Registered_users", where some or all the details can be filled out, depending on how they registered.

On one of my sites I have one table responses, which can be general (Email; form to me), about a message I posted, or about pictues in one of the galleries. All in one, with one colum the itemtype they replied to, and one the ID of the item they replied to.