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

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?