Is it best practice to combine MySQL data tables?

Question

I am considering changing a database scheme to reduce the number of tables. I have several tables that contain different-yet-similar data, and am wondering if it is best practice to leave it this way, or if there would be complications with combining them.

For example, let's say I have the following two tables:

Table `status`

`status_id` | `status_text`
---------------------------
1           | Open
2           | Closed
3           | On Hold

Table `type`

`type_id`   | `type_text`
---------------------------
1           | Regular Work
2           | Advanced Work
3           | Warranty Work

Would it be advantageous to combine these into a table, such as the following?

Table `text`

`id`        | `type`        | `text`
-------------------------------------------
1           | 1             | Open
2           | 1             | Closed
3           | 1             | On Hold
1           | 2             | Regular Work
2           | 2             | Advanced Work
3           | 2             | Warranty Work

The type column would correlate to PHP constants representing the data set type.

I currently have probably 6 tables with data in this exact scheme. It just bugs me that they are so similar, and each only holds 2-5 rows. I really want to combine them as I have above, but am not sure if there would be complications down the road from it, or if it is breaking best-practices.

I do realize the id column would conflict and would not be candidate for a primary key, but it would be a unique key along with type to prevent collisions. I am not worried about auto_increment, as these tables are managed manually.

Also another thing to keep in mind is that these tables are involved in several JOINS. I don't see it complicating the JOINs much more other than adding one more condition to the ON clause.

I apologize if this is a duplicate question, it seemed a hard subject to look up, as I am not posing a common question about selecting the data, but rather the scheme.

Answer 1

No. This is not OK. You're going backwards in proper database design/normalization and needlessly obfuscating your data.

Sure you can do this, but you'll regret doing it at some point in the future. Do you really want to be presented with a question like: "Hey Demonslay335, what Text type is this work type in the Text type table? Can you type that out for me? Typey-type type type."

Saying a word enough times turns it into gibberish, just like meta-typing your data.

Answer 2

If you have different constraints, you should use separate tables, even if the data "looks" similar.

For example, you can define FOREIGN KEYs towards different referencing tables very naturally if the lookup tables are separate.

The same would be harder to do if you put everything in the same table. Purely declarative way would be to migrate the type along the FK and then have a CHECK in the referencing table to ensure the correct type. Unfortunately, MySQL doesn't enforce CHECKs, so you'd need to enforce the right type through triggers or (God forbid) application logic.

Answer 3

There are pros and cons, and it often comes down to personal preference. I personally prefer multiple disparate lookup tables (since each one corresponds to a different entity definition within my domain, despite being composed of coincidentally similar primitive types). Others sometimes prefer the single "super lookup" table for the reasons you state.

One approach I've often seen is to have something like this:

LookUp
----------
ID
LookUpTypeID
Value
DisplayText
etc.

LookUpType
----------
ID
Name

This provides a fairly straightforward way to organize your lookup values into the single structure. And if you ever find yourself wanting to separate out the types to "mimic" the disparate tables (for example, if a developer like me joins your team and makes a lot of noise), you can always create views based on the types and use those in queries.

There's nothing inherently wrong with multiple small tables. If the data they contain genuinely means something different then I would argue that it should be separated. The conceptual meaning of the entities in the domain is far more important than the data types of which they're composed.

And multiple small tables makes little difference to the database engine. It's pretty optimized, you're not doing it any favors by combining the tables. In fact, you may find that your queries become slightly more obtuse over time as you do this. The meaning of the data being queried from the database starts to get clouded by implementation details within the tables. You can mitigate this by adding views to logically separate the data again, but if you find yourself needing to do that then why combine it in the first place?

Answer 4

I don't see any reasons to combine the tables into one table.

One thing i would consider is using an enum column. Where you have columns which are foreign keys referencing status , instead make them enums. You can then dispense with the table entirely. This results in a simpler schema. However, it has some weaknesses (some go so far as to call it evil ); for instance, if you use the same enumeration in several places, you have no guarantee that all the definitions are the same, and there is a risk that as the database evolves, they will get out of sync. Still, we use them quite a lot in our schema, and haven't really felt any pain from that.