views:

27

answers:

2

In all of our current databases, we use a (null allowed) ID field which auto-increments at every new row insert as well as a particular member ID (unique to every person and every row).

In essence, a person can be represented by ID=33 as well as MEMBERID=4839283789.

I have debated completely wiping the ID field and only using the MEMBERID as the primary key. Are there any advantages or disadvantages to either way?

A: 

Typically I use such an id row as the member/user id.

I'd keep it in to ensure the integrity of the table and that the rows can be uniquely identified. Otherwise you have to programatically ensure the member id is unique. Do your joins against either.

GrandmasterB
GrandmasterB - I build the memberid myself with a complex function then check to see if it exists in the DB so I'm not worried about duplicating it. Mainly focused on the two fields rather than likelihood it could be duplicated.
JM4
+1  A: 

Chances are that MEMBERID is populated from some 3rd party system and is just a link to it. I'd get a complete understanding of all of the systems using that database(s) before removing the field. If it ain't broke, I wouldn't worry too much about it.

The one thing that is a bit of a concern is that the ID field is presumably the primary key so it should not allow null entries.

hafichuk
? I create the memberid. It is my database and site. There is no 3rd party involved.
JM4