[ic] Merge perge for user database

Paul Jordan paul at gishnetwork.com
Sat Nov 8 10:10:39 EST 2003

Ed LaFrance [edl at newmediaems.com] wrote:
> At 09:56 AM 11/8/2003 -0500, you wrote:
>> Is there a built in way to handle merging of customer accounts?
>> i.e. if a customer orders and does not log in, they get new accounts
>> each time. If they then call in an order later, and we find that
>> they have many accounts, we would like to merge them into 1.
>> Thanks
>> Rick
> You would have to do this manually, though you could probably write a
> script to handle it; there is no built in feature for this. In
> practice, once you have decided which userdb account will be primary,
> it is just a matter of inserting that customer ID in the username
> field of all affected records in the transactions table, then
> deleting the redundant
> userdb records.
> - Ed L.

Yes, and orderline has a username column as well.

So, decide the primary, then iterate through all transactions and orderlines
and swap old username for primary username. Then, take the old userdb's
'order_numbers' and append them to the primary userdb's 'order_numbers' column.

That should be all there is, assuming you never implemented advanced tables
like "order_returns" or "forum", etc.

The only hard part will be how to associate old and new usernames via ADMIN.
Your best bet is probably to make the UPDATE/DELETE query, then just copy paste
the old username with the primary username (into the query). You would have to
retrieve them first by manually searching obviously. I probably would not write
a script that compares addresses and automatically merges.

You could make two pages. One, that show results of similar
addresses/names/whatever in a row. Each record would have a:

  radio    	() primary account
  checkbox	[] merge account

and each row would have a checkbox:

		[] merge these records

Your query could be built in from that.

I avoided this by requiring login. If you don't require log in, it makes life
harder not only for you but for the customer. If a customer signs up for a
newsletter everytime he makes a purchase, it will be a bear to
unsubscribe/maintain subscriptions. If you want to offer advanced features like
personalized tools, they need log in as well. Having an order history/status is
a tool to mitigate customer service, which is really useless if they don't have
a real account.

I would rather have one record a user can control, know what he is subscribed
to, what he is not, and all his orders. I don't like one person having 20
userdb records. It probably also depends on your product though.

I think subliminally to a consumer, requiring login is a bit of a turn off.
However, they won't admit that it does instill confidence that it is not just
some hack job that will send/save your CC number in the clear to some punk teen
that drives around in a 71' primer grey camero with t-tops that steals your
lunch money even after my mom called the principle...

Ugh... anyways, 90% of all my purchases are on the web, and 99% of the sites I
use require login.


More information about the interchange-users mailing list