Question

I have a database design problem which I have been researching for a while but cannot get a proper answer. Let’s say we have two tables, house_schema and house as follows:

house_schema {
      id big int,
      house_height int,
      house_width int,
      house_decoration vchar(1024),
      build_date  timestamp,
      primary key id,
}

house {
      id big int,
      owner vchar(255),
      price big int,
      house_schema_id big int,
      primary key id,
      foreign key fk_house_house_schema_id (`house_schema_id`) reference `house_schema`.`id`
}

The house_schema table stores some physical attributes of house. On a software UI, users select a schema then click a “build” button. A house is built and is stored in house. There are some other tables like house_schema to describe how a house should be built.

In a simple design, a foreign key seemingly works well. However, it gives rise to a problem when the builder decides to remove a schema that they think is out of date. There are already some houses built from the schema and the foreign key prevents it from deleting. If we change the foreign key to DELETE ON CASCADE, then those houses lose the information it was built from.

What’s the best design pattern to handle this problem? What I can imagine is having a duplicate table of house_schema, once a house has been built, copy the row in house_schema to the duplicate table.

But, this leads to a lot of duplicate tables in the database as I have multiple similar tables with house_schema. It seems to violate database normalization rules.

Does anybody have a good idea?

Answer 1

If you like to retain a history of what schema’s were used to build houses, a typical solution would be to implement a soft delete on your house_schema table.

Instead of actually deleting the rows in house_schema you would have to

• add a Active column to the table
• set this column to false when a schema is obsolete
• adjust your application to not show the inactive schema’s

Note that there’s quite some material about soft delete, both advising against and for.

• Are soft deletes a good idea
• The trouble with soft delete
• Soft deletes are bad?

From personal experience, we employ soft delete on selectable items (drop down lists) in our main application without any mentionable problems so far.

When an item becomes obsolete, it’s value needs to be retained wherever it’s used but for new documents, it shouldn’t show up in de drop down lists anymore. I yet have to come across a better solution to be able to handle this scenario other than soft delete.