Is there a name for this pattern, representing one-to-many relationships by adding columns with an index to a single table?

Question

So a domain expert wants the following relation:

CarOwners(owner_id, name, address, car_1_registration, car_2_registration, car_3_registration, car_4_registration)

The reason given that most people are unlikely to have more cars than that, and that it's easier to reason with than the general case of an arbitrary number of cars. This seems like a common pattern for Excel jockeys, whereas for a DBA it would be much easier to simply have a separate relation:

Car(registration, owner_id)

But this idea is hard to sell to anyone who doesn't know what a JOIN is.

I looked in database literature and couldn't find any references to this (arguably anti-)pattern. Perhaps there's nothing theoretically wrong with it (it's just impractical), or it's simply too goofy to even be considered by academics. But it would be interesting to hear if it's actually covered.

Answer 1

(it's just impractical)

Interesting, the purpose might be served. Smart Technology for the Smart people. Database comes to play in his roles due to overcome these issue.

The main problem with this is, it's not extensible If 'car_5_registration' comes on the floor.

Answer 2

The Domain Expert has given you a requirement disguised as an implementation detail. I would implement this by:

• Implementing a relation table as you want
• Implementing a view which will give up to 4 associated registrations per owner

When an owner registers a fifth registration the system should keep working with no problem (which is probably what the DE wants) but the view he uses for reporting will still only show 4 registrations. (Maybe the view could include the total number of registrations per owner as well?)

This way you may have to change the view (used only for reporting) every now and then, rather than have to change a major table and all the relations and code that will be affected.