Better to create connections between related db columns using 'Index' or using a query?

Question

I'm wondering what would be the best way to create connections between related db columns - in a query or by using Index? I know that the primary concern with using Index is performance speed, and I don't believe that is an issue here.

Each column in the table represents various product attributes, and many of the columns are directly connected to a few other other columns (typically 2 - 3 columns), in one of these ways:

1. Alternate types of data for the same attribute (i.e. color name + hex# displayed, or image name + .png file name + alt value). The values in these columns represent the same information but in a different format, so there's a direct correlation between the values but the values themselves aren't identical.

2. Subsets used for purposes of categorizing the values in a column. The same values exist in more than one column (with either a parent/child or sibling relationship). For example, the "Colors All" column is subdivided into 5 columns indicating different types of colors (i.e. Dark, Light, Bright, etc.), and most of those groups are further subdivided into 3 categories (ranked by degree of darkness, etc.). The color Navy is in 3 columns - "Colors All", "Dark Colors" and "Jewel Tones".

In the past I've only used Index to create relationships between tables (using foreign keys), but it seems like this might save me from having to create statements connecting them each time.

At the moment I'm using mySql with PDO fetch statements (but I may be switching databases within the next 12 months)

Answer 1

I should start by clarifying that query and Index are not alternatives of each other.

When a table is created, columns are defined and some of these columns can be defined as FOREIGN KEYS, relating to other column(s) in another table. The relation between tables is only useful for referential integrity purposes (if the engine supports it). It's also useful for documentation purposes and some query designers use them to guess the joins in a query.

The indexes (or indices) serve a different purpose. They tell the database to create an additional data structure that servers to speed-up retrieval of rows base on values of the indexed columns.

So, FOREIGN KEYs define relationships between tables, queries join the related tables, and indexes speed up the joining, filtering, grouping, and sorting operations in a query.

Edit: A table is used to represent a type of entity. So, we could have a table for colors with two attributes: colors(color_name, color_value). Color_value could be an hex string or an integer representation. In principle, we would not have a column for the color code in format rgb(x,y,z) because this can always be computed from the first.

We would have another table to keep the list of images. However, there is no relation between the table of colors and the table of images.

Edit 2: The second type is usually represented with two tables. The first table stores a typical hierarchical relation and the second table tells which classes each colour is labelled with. So, your relational model for the examples you provide would be:

colors(colorid, color_name, color_value)
color_classes(classid, classname, parentid)
colors_classes(colorid, classid)

e.g.,
(colorid, color_name, color_value) - colors
(1,       'Navy',     'xxx')

(classid, classname,    parentid) - color_classes
(1,      'All colors',    0)
(2,      'Dark colors',   1)
(3,      'Light colors',  1)
(4,      'Jewel Tones',   2) -- assuming Jewel Tones is a subdivision of Dark Colors

(colorid, classid) - colors_classes
(1,       4)       -- assuming Jewel Tones is a subdivision of Dark Colors

You should also be aware that recursive relations (as in color_classes) are not gracefully handled in the relational model, but they are still quite common and there are solutions to deal with it.

Finally, I'm not sure that the relational model is indeed the best for your problem. It will depend on the use you want to make of the data.