Question

I’ve asked this question here, but I don’t think I got my point across.

Let’s say I have the following tables (all PK are IDENTITY fields):

• People (PersonId (PK), Name, SSN, etc.)
• Loans (LoanId (PK), Amount, etc.)
• Borrowers (BorrowerId(PK), PersonId, LoanId)

Let’s say Mr. Smith got 2 loans on his name, 3 joint loans with his wife, and 1 join loan with his mistress. For the purposes of application I want to GROUP people, so that I can easily single-out the loans that Mr. Smith took out jointly with his wife.

To accomplish that I added BorrowerGroup table, now I have the following (all PK are IDENTITY fields):

• People (PersonId (PK), Name, SSN, etc.)
• Loans (LoanId (PK), Amount, BorrowerGroupId, etc.)
• BorrowerGroup(GroupId (PK))
• Borrowers (BorrowerId(PK), GroupId, PersonId)

Now Mr. Smith is in 3 groups (himself, him and his wife, him and his mistress) and I can easily lookup his activity in any of those groups.

The problems with new design:

The only way to generate new BorrowerGroup is by inserting MAX(GourpId)+1 with IDENTITY_INSERT ON, this just doesn’t feel right. Also, the notion of a table with 1 column is kind of weird.

I’m a firm believer in surrogate keys, and would like to stick to that design if possible.

This application does not care about individuals, the GROUP is treated as an individual

Is there a better way to group people for the purpose of this application?

Answer 1

The design of the database seems OK. Why do you have to use MAX(GourpId)+1 when you create a new group? Can’t you just create the row and then use SCOPE_IDENTITY() to return the new ID?

e.g.

INSERT INTO BorrowerGroup() DEFAULT VALUES
SELECT SCOPE_IDENTITY()

(See this other question)

(edit to SQL courtesy of this question)