Объединение таблиц базы данных

Question

У меня есть две таблицы, которые выглядят примерно одинаково, и я думал об их объединении и думал, что получу некоторую информацию от всех Вот как они сейчас выглядят:

Вопросы * * 1003

Id  | IssueCategory   | IssueType | Status | etc..
-------------------------------------------------
123 | Copier          | Broken     | Open   |
124 | Hardware        | Missing    | Open   |

CopierIssueDetails

Id | IssueId | SerialNumber | Make | Model    | TonerNumber | LastCount
---------------------------------------------------------------------
1  | 123     | W12134       | Dell | X1234    | 12344555    | 500120

HardwareIssueDetails

Id | IssueId | EquipmentNumber | Make | Model | Location  | Toner | Monitor | Mouse 
-----------------------------------------------------------------------------------
1  | 124     | X1123113        | Dell | XXXX  | 1st floor | 0     | 1       | 0

Что вы думаете о объединении этих двух таблиц в одну. Будет ли это хорошей идеей или лучше разделить их так?

Answer 1

В конечном итоге вопрос сводится к следующему: «Это соотношение один к одному или один ко многим?» Если когда-либо есть возможность иметь два или более элементов в данной таблице, связанных с элементами в другой таблице, держите их отдельно. Если нет, то их объединение упростит ваши запросы.

Answer 2

В этих ситуациях я рассматриваю одну вещь: «Как эти вещи будут развиваться?». Например, если вам нужно добавить новый столбец для копиров, какова вероятность того, что аппаратному обеспечению понадобится этот же столбец? Как насчет отчетов, вам обычно приходится объединять информацию, или у вас обычно есть отдельные отчеты для двух типов?

Если эти две вещи могут развиваться / использоваться по отдельности, то я бы рекомендовал игнорировать тот факт, что они выглядят очень похоже; В противном случае вы получите особые случаи, засоренные по всем вашим запросам.

Answer 3

Мне нужна убедительная причина, чтобы объединить их, потому что они не выглядят одинаково. Может быть, есть веская причина, но я не вижу предложенной.

В механическом исполнении перед лицом решения стоит вопрос, достаточно ли две части одинаковы, чтобы называться одним и тем же номером детали, или они разные и заслуживают разных PN. Правило, чтобы решить это - «Форма, Приспособление, Функция».

• Форма: Они "достаточно одинаковы?"
• Fit: Они взаимозаменяемы?
• Функция: Они выполняют одинаково цель, удовлетворить ту же потребность?

Вы можете попробовать применить этот критерий к вашей схеме.

Answer 4

Вопросы для рассмотрения:

1. Есть ли в таблицах разные данные?Я усиленно избегаю создания слишком общих полей.В этом случае, «Серийный номер» и «Номер оборудования» звучат так, как будто они могут быть практически одинаковыми.Но «Last Count» не будет применяться к компьютеру, а «Monitor» и «Mouse» не применимы к любому копиру, который я знаю.Да, вы можете оставить эти поля пустыми, если они не применимы.Если вы объединяете, я настоятельно рекомендую вам НЕ создавать поле, содержащее код «Мышь» для компьютеров и Счетчик для копиров.Так лежит безумие.Но вы можете включить оба набора полей и оставить их пустыми, если это не применимо.

2. Таблицы используются по-разному?Если у вас есть один набор вещей, которые вы делаете или ожидаете сделать, которые работают только с аппаратными проблемами, и другой набор вещей, которые работают только с проблемами копировального аппарата, и мало или ничего, что работает на обоих, это хорошая причина, чтобы разделить их.Если есть много операций, которые обрабатывают обе, и вы постоянно пишете UNION для двух таблиц, это признак того, что они действительно должны быть одной таблицей.Хотя я считаю, что в принципе ваша схема должна моделировать реальный мир, с которым вы имеете дело, и код должен следовать за схемой, на практике, если при написании кода вы постоянно видите, что с другой схемой будет проще работать,это сильный признак того, что вы НЕ точно моделируете реальный мир, с которым имеете дело.

3. Какие будущие данные вы, вероятно, создадите?Есть ли шесть других типов «проблем», с которыми вы будете иметь дело, так что вместо 3 таблиц у вас скоро будет 9?Если да, то какие данные они будут нести?Как они будут использоваться?Или это вероятно?

Я бы посчитал производительность последней.Изменение схемы для повышения производительности должно выполняться только после того, как производительность окажется проблемой, или когда вы выполнили некоторые реальные тесты, чтобы продемонстрировать, что это произойдет.В базах данных сделано много преждевременной оптимизации производительности, которая фактически практически не улучшает производительность, но приводит к ненормализованным и небрежным данным.

Answer 5

Ну, это зависит от того, насколько велика эта сложность в будущем.

Если будет только несколько типов проблем, отличающихся несколькими конкретными полями и имеющими много общих полей, имеет смысл объединить их все в одно и оставить поля пустыми, которые не применяются в конкретном случае.

Другим подходом может быть объединение всех общих полей в одну таблицу и добавление еще одной общей таблицы дополнительных сведений со структурой, подобной:

IssueID
FieldName
FieldValue_Text
FieldValue_Number
FieldValue_Float

и может быть основной таблицей для дополнительных имен полей с такими столбцами:

FieldID
FieldName
DataType

В конце концов, я бы сказал, что это КОНТЕКСТ, который оправдал бы любой замысел, и трудно ответить на ваш вопрос, не глядя на полную картину.

Answer 6

Вы, конечно, могли бы, хотя вы можете сделать несколько более общих столбцов, чтобы у вас не было пустых столбцов. Например, вы знаете, что в копирах нет мониторов или мышей, поэтому для строки копира не имеет смысла иметь столбец монитора / мыши. Вы можете сделать эти столбцы более общими, изменив их на один столбец с именем «HardwareType» со значениями:

0 = монитор,

1 = Мышь,

2 = монитор и мышь,

3 = Копир

(Затем вы можете поместить это в справочную таблицу, чтобы отслеживать ваши идентификаторы).

Вещи, которые вы хотите рассмотреть:

1) При объединении этих таблиц скорость приложения увеличивается?

2) При объединении этих таблиц повышается уровень обслуживания приложения?

Если таблицы очень большие и используются для разных задач, это может быть нецелесообразно. Для таблиц, которые «примерно одинаковы» с точки зрения концепции, то неплохо объединять их, если это не влияет на производительность, и если вы избегаете множества ненужных столбцов, которые относятся только к определенным элементам, но не другие.