Is having all entity tables inherit from one main entity table a bad idea? My co-worker is designing a schema where most entities (like contacts, quotes, tasks) inherit from an "entity" table, which keeps track of things like which tenant owns the entity, and chagnes to the entity. This is similar to VTiger CRM's schema.

Is this a terrible idea? What should I tell him the problems are?

Is there a name for this pattern?

ENTITY
id PK
tenant FK TENANT
version
draft
deleted

ENTITYCHANGE
entityId PK FK ENTITY
version PK FK ENTITY
createdBy
createdAt
fieldName
fromValue
toValue

CONTACT
id PK FK ENTITY
name
[other contact fields]

QUOTE
id PK FK ENTITY
contactId FK CONTACT
[other quote fields]
Yes, there are some issues with this design.  The pattern is Entity-Attribute-Value at least for the EntityChange table.  See the link for all the reasons why this almost always should be avoided.

The Entity table itself may not be EAV, but it does nothing but increase complexity without adding any value.  To know if a Contact has another tenant, another version, another draft, or is logically deleted you have to join.  Even if none of these are applicable to the Contact table, your design dictates their existence and accommodation.

If you decide that Contacts can be logically deleted then add a deleted column to the contact table.  If you decide you need different drafts of Contacts, then add a drafts column, etc.  Essentially, there is no advantage to moving these attributes to a common table.  It increases storage requirements, reduces performance more than it helps, and make the system more complex.