mysql - Is using a Master Table for shared columns good practice for an entire database?

Question

Below, I explain a basic design for a database I am working on. As I am not a DB, I am concerned if I am on a good track or a bad one so I wanted to float this on stack for some advice. I was not able to find a similar discussion that fit's my design.

In my database, every table is considered an entity. An Entity could be a customer account, a person, a user, a set of employee information, contractor information, a truck, a plane, a product, a support ticket, etc etc. Here are my current entities (Tables)...

• People
• Users
• Accounts
• AccountUsers
• Addresses
• Employee Information
• Contractor Information

And to store information about these Entities I have two tables:

Entity Tables
-EntityType
-> EntityTypeID (INT)
-Entities
-> EntityID (BIGINT)
-> EnitityType (INT) : foreign key

Every table I have made has an Auto Generated primary key, and a foreign key on an entityID column to the entities table.

In the entities table I have some shared fields like,

• DateCreated
• DateModified
• User_Created
• User_Modified
• IsDeleted
• CanUIDelete

I use triggers on all of the table's to automatically create their entity entry with the correct entity type on inserts. And update triggers update the LastModified date.

From an application layer point of view, all the code has to do is worry about the individual entities (except for the USER_Modified/User_Created fields "it does updates on that" by joining on the entityID)

Now the reason for the entities table, is down the line I plan on having an EAV model, so every entity type can be extended with custom fields. It also serves as a decent place to store metadata about the entities (like the created/modified fields).

I'm just new to DB design, and want a 2nd opinion.

Answer 1

I plan on having an EAV model, so every entity type can be extended with custom fields.

Why? Do all your entities require to be extensible in this way? Probably not -- in most applications there are one or two entities at most that would benefit from this level of flexibility. The other entities actually benefit from the stability and clarity of not changing all the time.

EAV is an example of the Inner-Platform Effect:

The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with.

In other words, now it's your responsibility to write application code to do all the things that a proper RDBMS already provides, like constraints and data types. Even something as simple as making a column mandatory like NOT NULL doesn't work in EAV.

It's true sometimes a project requires a lot of tables. But you're fooling yourself if you think you have simplified the project by making just two tables. You will still have just as many distinct Entities as you would have had tables, but now it's up to you to keep them from turning into a pile of rubbish.

Before you invest too much time into EAV, read this story about a company that nearly ceased to function because someone tried to make their data repository arbitrarily flexible: Bad CaRMa.

I also wrote more about EAV in a blog post, EAV FAIL, and in a chapter of my book, SQL Antipatterns: Avoiding the Pitfalls of Database Programming.