2 added 4 characters in body
source | link

You're right; the membership ID is not part of your Primary Key. That's why synthetic keyssynthetic keys exist.

A synthetic key is one that is automatically generated, either by you or the database. It usually takes the form of either an incrementing number or a globally-unique identifier. Synthetic keys are never re-used, even if a record is deleted. The good ones are guaranteed to be unique across the entire database, or even across any database.

Synthetic keys don't take on any characteristics of the data they represent. They are, in fact, completely independent of your data, except for the relationships they impart by matching with foreign keys in your other tables.

In short, synthetic keys don't suffer from any of the problems that other kinds of keys do. Each and every one of your tables should contain a synthetic primary key and relationships defined by joining those keys to corresponding foreign keys in other tables.

Naturally, you can add other fields like Membership ID. Avoid using these fields in table relationships, however, except possibly as joins in ad-hoc queries.

Changes to database schemas do happen, but usually only in response to new business requirements. The most common changes made to production databases is that tables or fields are added.

You're right; the membership ID is not part of your Primary Key. That's why synthetic keys exist.

A synthetic key is one that is automatically generated, either by you or the database. It usually takes the form of either an incrementing number or a globally-unique identifier. Synthetic keys are never re-used, even if a record is deleted. The good ones are guaranteed to be unique across the entire database, or even across any database.

Synthetic keys don't take on any characteristics of the data they represent. They are, in fact, completely independent of your data, except for the relationships they impart by matching with foreign keys in your other tables.

In short, synthetic keys don't suffer from any of the problems that other kinds of keys do. Each and every one of your tables should contain a synthetic primary key and relationships defined by joining those keys to corresponding foreign keys in other tables.

Naturally, you can add other fields like Membership ID. Avoid using these fields in table relationships, however, except possibly as joins in ad-hoc queries.

Changes to database schemas do happen, but usually only in response to new business requirements. The most common changes made to production databases is that tables or fields are added.

You're right; the membership ID is not part of your Primary Key. That's why synthetic keys exist.

A synthetic key is one that is automatically generated, either by you or the database. It usually takes the form of either an incrementing number or a globally-unique identifier. Synthetic keys are never re-used, even if a record is deleted. The good ones are guaranteed to be unique across the entire database, or even across any database.

Synthetic keys don't take on any characteristics of the data they represent. They are, in fact, completely independent of your data, except for the relationships they impart by matching with foreign keys in your other tables.

In short, synthetic keys don't suffer from any of the problems that other kinds of keys do. Each and every one of your tables should contain a synthetic primary key and relationships defined by joining those keys to corresponding foreign keys in other tables.

Naturally, you can add other fields like Membership ID. Avoid using these fields in table relationships, however, except possibly as joins in ad-hoc queries.

Changes to database schemas do happen, but usually only in response to new business requirements. The most common changes made to production databases is that tables or fields are added.

1
source | link

You're right; the membership ID is not part of your Primary Key. That's why synthetic keys exist.

A synthetic key is one that is automatically generated, either by you or the database. It usually takes the form of either an incrementing number or a globally-unique identifier. Synthetic keys are never re-used, even if a record is deleted. The good ones are guaranteed to be unique across the entire database, or even across any database.

Synthetic keys don't take on any characteristics of the data they represent. They are, in fact, completely independent of your data, except for the relationships they impart by matching with foreign keys in your other tables.

In short, synthetic keys don't suffer from any of the problems that other kinds of keys do. Each and every one of your tables should contain a synthetic primary key and relationships defined by joining those keys to corresponding foreign keys in other tables.

Naturally, you can add other fields like Membership ID. Avoid using these fields in table relationships, however, except possibly as joins in ad-hoc queries.

Changes to database schemas do happen, but usually only in response to new business requirements. The most common changes made to production databases is that tables or fields are added.