Is creating a "dummy record" to force data-base obey the business logic, a good idea or a dumb one?

In some projects I see that a dummy record is needed to create in Db in order to keep the business logic go on without breaking the Db constraints.

So far I have seen its usage in 2 ways:

By adding a field like IsDummy
By adding a field something called ObjectType which points a type: Dummy

Ok, it helps on what needs to be achieved.

But what makes me feel alert on such solutions is sometimes you have to keep in mind that some dummy records exist in the application which needs to be handled in some processes. If not, you face some problems until you realize their existence or until someone in the team tells you "Aha! You have forgotten the dummy records. You should also do..."

So the question is: Is it a good idea to create dummy records to keep business logic as it is without making the Db complain? If yes, what is the best practice to prevent developers from skipping their existence? If not, what do you do to prevent yourself from falling in a situation where you end up with an only option of creating a dummy record?

Thanks!

Solution

Using dummy records is inferior to getting the constraints right.

There's often a temptation to use them because using dummy records can seem like the fastest way to deliver a new feature (and maybe sometimes it is), but they are never part of a good design, because they hide differences between your domain logic and data model.