-1

Why would a DBA choose to have a large, heavily referenced lookup table instead of several small, dedicated lookup tables with only one or two tables referencing each one. For example:

CREATE TABLE value_group (
   id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
   group_name VARCHAR(30) NOT NULL
);

CREATE TABLE value_group_value (
   id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
   value_group_id INT NOT NULL,
   value_id INT NOT NULL,
   FOREIGN KEY (value_group_id) REFERENCES value_group(id)
);

CREATE TABLE value (
   id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
   value_text VARCHAR(30) NOT NULL
);

Example groups would be something along the lines of:

  • 'State Abbreviation' with the corresponding values being a list of all the U.S. state abbreviations.

  • 'Name Prefix' with the corresponding values being a list of strings such as 'Mr.', 'Mrs.', 'Dr.', etc.

In my experience normalizing these value tables into tables for each value_group would make changes easier, provides clarity, and queries perform faster:

CREATE TABLE state_abbrv (
   id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
   abbreviation CHAR NOT NULL
);

CREATE TABLE name_prefix (
   id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
   prefix VARCHAR NOT NULL
);

With n tables like that for n groups in the value_group table. Each of these new tables could then be directly referenced from another table or using some intermediary table depending on the desired relationship.

What factors would influence a DBA to use the described the first setup over the second?

  • 2
    I'm having a little trouble understanding your examples. Can you edit your question to provide some less abstract examples? Is this essentially a question about DB normalization? Also, this is probably suited for dba.SE. – RToyo Sep 29 '17 at 19:23
  • @RToyota, it looks like he's asking "multiple dedicated lookup tables" vs. "single table of tables" (well, three in his case). – Brian Sep 30 '17 at 01:06
  • 1
    William, in order to answer we'll need to know your criteria for "better", but I'm afraid the answer will still be some variation of "it depends - go and test and see which works better for you". – Brian Sep 30 '17 at 01:07
  • My apologies, I've clarified my original question. It sounds like @Brian has the general idea of the question. – William Perry Oct 01 '17 at 00:31
  • Yeah @Brian does, but his point is your question has no answer except what you get by measuring. However, it is not even clear how one design is a transformation of the other. Generally, if you have a bunch of tables that could be unioned together then that's the straightforward design, and if you have a bunch of tables that are projections of their joins they should be decomposed per normalization, and if you don't know this then you have a lot of basics to learn before "efficiency" is going matter from your point of view. (Like so many questions like this you should have found googling.) – philipxy Oct 01 '17 at 02:24
  • Possible duplicate of [What's better - many small tables or one big table?](https://stackoverflow.com/questions/4089830/whats-better-many-small-tables-or-one-big-table) – philipxy Oct 01 '17 at 02:30
  • [Please don't use links/images for what can be expressed by text.](https://meta.stackoverflow.com/questions/285551/why-not-upload-images-of-code-on-so-when-asking-a-question/285557#285557) Like these diagrams. Non-text can be a nice in *addition*. Also please don't ask a question unless reading *many* hits from googling *many* clear, concise, specific variants of your question/problem/desideratum with & without various tags fails. if so ask with one as title. (Not a vague title like here.) This question is too vague & too broad *and* a faq. An answer is DB design & optimization book chapters. – philipxy Oct 01 '17 at 02:42
  • Thanks @philipxy for the link to the other question but I had found questions like that. I dont feel that they adequately answer what I'm asking. I'll edit my question again to further clarify, but your comment to 'read a book' or 'learn normalization' is completely unhelpful. I already know what normalization is. Part of why I'm asking this question as I've seen both table setups used in production. – William Perry Oct 02 '17 at 13:38
  • I said, "*if* you don't know this", and my general answer was to a general question. And you don't seem to realize how much small details can affect performance. Your edit would be clearer & shorter if you gave DDL & example data for both designs. It's still not clear what the 2nd design is--partly because there doesn't seem to be any normalization here, rather there seems to be some kind of partitioning reversed by union, and partly because the partitions need no group column. (Normalization replaces a table by projections that join to it.) – philipxy Oct 02 '17 at 14:46
  • The DDL makes some things clear. But again: The 2nd design is still not given and are still expecting us to know what it is via your use of "normalization" but that is *not clear* and from what else you have written is an inapropriate use of that word. Also the illustrations still don't agree with your other descriptions. Please just address everything in my comments. PS See [this answer](https://stackoverflow.com/a/24196511/3404097). – philipxy Oct 03 '17 at 01:36

1 Answers1

0

In my experience, the primary advantages of a single, standardized "table of tables" structure for lookups are code reuse, simplified documentation (if you're in the 1% of folks who document your database, that is) and you can add new lookup tables without changing the database structure.

And if I had a dollar for every time I saw something in a database that made me wonder "what was the DBA thinking?", I could retire to the Bahamas.

Brian
  • 1,238
  • 2
  • 11
  • 17