Если кодированные_1, кодированные_2 и т. Д. Все используются в качестве ключей поиска для одной и той же таблицы, звучит так, будто все они являются «одной и той же идеей».Но я сначала подумал, что лучший дизайн в этом случае будет:
big_table (trans_id, var_id, encoded_var)
lookup_table (encoded_var, decoded_desc)
Тогда запрос просто становится:
select trans_id, var_id, encoded_var, decoded_desc
from big_table
join lookup_table on lookup_table.encoded_var=big_table.encoded_var
Я не знаю, является ли это реальным полемимя или если вы просто пытаетесь опустить не относящиеся к делу детали.Вы можете опустить соответствующие детали здесь.В чем разница между encoded_1 и encoded_2 и т. Д.?Если они являются взаимозаменяемыми, нет никаких причин иметь отдельные поля для них.Действительно, это вызывает много проблем.Даже если есть семантическая разница, если они все используют одну и ту же таблицу поиска, все они должны приходить из одного домена.
Например, несколько лет назад я работал над системой для управления техническими руководствами, которыенаша организация производится и используется.В каждом руководстве было 3 менеджера.(Администратор, который обрабатывал бюджеты и графики, менеджер по запасам, который отслеживал, кому нужны копии, и следил за тем, чтобы они были получены, и менеджер по контенту, отвечающий за фактический текст.) Но все они были взяты из одного и того же списка людей,как часто один и тот же человек может иметь более одной из этих ролей или может иметь разные роли для разных руководств.Поэтому мы составили таблицу «людей» с идентификатором, именем, адресом электронной почты и т. Д., А затем в основной ручной записи я создал 3 столбца, по одному для каждого типа менеджера.
Это была огромная ошибка.Я должен был создать отдельную таблицу с ручным идентификатором, идентификатором типа менеджера и идентификатором человека, а затем иметь 3 ЗАПИСИ для 3 типов менеджера, а не 3 поля в одной записи.
Почему?С тремя столбцами я столкнулся с той же проблемой, которую вы описываете, хотя и в меньшем масштабе: мне пришлось трижды присоединиться к таблице ручного режима к таблице личных данных.Вопрос типа "за какие книги отвечает Боб Смит?"потребовался удивительный сложный запрос, что-то вроде
select ... whatever ...
from manual
join person p1 on p1.person_id=manual.admin_id
join person p2 on p2.person_id=manual.stockmanager_id
join person p3 on p3.person_id=manual.contentmanager_id
where p1.name='Bob Smith'
or p2.name='Bob Smith'
or p3.name='Bob Smith'
С одним столбцом это было бы просто
select ... whatever ...
from manual
join manual_manager on manual_manager.manual_id=manual.manual_id
join person on person.person_id=manual_manager.person_id
where person.name='Bob Smith'"
При всех повторениях, было не удивительно, что было нескольковремя, когда программист случайно проверял только 2 поля вместо всех 3. С 1 полем эта ошибка была бы невозможна.С 3 полями, если бы мы добавили менеджер 4-го типа, нам пришлось бы добавить еще один столбец, а затем изменить каждый запрос, который просматривал эти поля.С 1 полем мы, вероятно, не будем.И т. Д.
С 3 полями нам потребовалось 3 индекса, и есть другие факторы, влияющие на производительность.
Я подозреваю, что к вам относится тот же тип мышления.все они полностью взаимозаменяемы, тогда таблице потребуется только порядковый номер для создания уникального pk.Если между ними есть какая-то разница, вы можете создать код для их различения.