Should I make separate table for data with similar structure

Question

I have many tables contain a field for its "type/category/group". This field references to its respective tables, for example :

item -> item_category, queue -> queue_group, stock -> stock_type, account -> account_type, patient -> patient_type, etc. All of them have exactly same table structure. Here is a simple example :

+---------------+---------------+
| name          | type          |
+---------------+---------------+
| id            | INT(AI)       |
| name          | VARCHAR(255)  |
| description   | TEXT          |
+---------------+-------------- +

The question is, should I create separate tables for each data references (item_category, queue_group, stock_type, account_type, patient_type, etc), or should I create a single reference table for all those data ? for example :

+---------------+---------------+
| name          | type          |
+---------------+---------------+
| id            | INT(AI)       |
| source        | INT           |
| name          | VARCHAR(255)  |
| description   | TEXT          |
+---------------+-------------- +

The "source" field is a simple implementation example to define which table a record belongs to.

The purpose is to make those item, category, queue etc data can lookup their "type/category/group" field in the same table to achive Less tables . What should I use and what are the pros and cons for each approach ?

Answer 1

The choice of one or many reference tables is actually rather arbitrary. Following normalization rules, the "correct" choice is to have a separate table for each reference table. This is a very reasonable approach.

Putting all the names into a single table could help or hinder performance. Assuming that the number of names is in the hundreds, or even a few thousands, then indexes would provide sufficient performance -- the performance impact of a single larger table should be about the same as for multiple tables. There is actually a potential for a gain in performance on some queries. Small reference tables are typically much smaller than a data page, so a bunch of small tables would occupy more pages than a large table. Once again, although a benefit for performance, the loss of a few pages in the cache would generally not be very noticeable from a performance perspective.

One important reason for using a single table is for management of such codes. For instance, if there are plans for internationalization (supporting multiple languages) then having the codes in one place is very helpful. Similarly, if you decide to make a blanket decision about the descriptions (say, abbreviations will not be allowed or you want to add in a short description), having them in one place is helpful. Or, if you decide to change the description from single byte characters to a national character set, then having them in one place is a help.

My conclusion is that having a single reference table for this purpose versus multiple reference table would have minimal impact on performance (unless you are dealing with lots and lots of codes). The default approach would be separate tables, the "correct" way in terms of normalization. But, if you have a reason for wanting all the codes in a single place, that is quite doable and also a reasonable solution.