Проектирование базы данных на основе структуры данных

Question

У меня есть структура данных примерно такая:

typedef struct tagSUB_DATA
{
    double measuredValue;
    double standardDeviation;
    double calculatedValue;
    double weightedError;

} SUB_DATA;

typedef struct tagALL_THE_DATA
{
    int aNumber;
    double aDouble;
    SUB_DATA measurements1;
    SUB_DATA measurements2;

} ALL_THE_DATA;

, который мне нужно хранить в реляционной базе данных.

Мой запрос относится к двум полям measurements1 и measurements2. Очевидно, они относятся к одному типу, поэтому моей первой мыслью было «давайте создадим таблицу SUB_DATA и создадим между ними ссылку на внешний ключ».

Table: ALL_THE_DATA
Field: ID (int, Primary Key)
Field: aNumber (int)
Field: aDouble (double)
Field: measurements1 (int, Foreign Key referencing SUB_DATA)
Field: measurements2 (int, Foreign Key referincing SUB_DATA)

Table: SUB_DATA
Field: ID (int, Primary Key)
Field: measuredValue (double)
Field: standardDeviation (double)
Field: calculatedValue (double)
Field: weightedError (double)

Однако фактический контекст данных таков, что measurements1 и measurements2 являются измерениями разных вещей (скажем, яблок и апельсинов ракет), которые оба нуждаются в измеряемом значении стандартное отклонение и т. д. Является ли по-прежнему уместным хранить данные для измеренных яблок и измеренных ракет в одной таблице, даже если они используют одни и те же данные, или было бы более разумно спроектировать их так, чтобы ракеты и яблоки есть свои (идентично спроектированные) таблицы?

Table: ALL_THE_DATA
Field: ID (int, Primary Key)
Field: aNumber (int)
Field: aDouble (double)
Field: appleMeasurements (int, Foreign Key referencing APPLE_MEASUREMENTS)
Field: rocketMeasurements (int, Foreign Key referencing ROCKET_MEASUREMENTS)

Table: APPLE_MEASUREMENTS
Field: ID (int, Primary Key)
Field: measuredValue (double)
Field: standardDeviation (double)
Field: calculatedValue (double)
Field: weightedError (double)

Table: ROCKET_MEASUREMENTS
Field: ID (int, Primary Key)
Field: measuredValue (double)
Field: standardDeviation (double)
Field: calculatedValue (double)
Field: weightedError (double)

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

Ура!

(Прошу прощения за мои псевдоданные Яблоки / Ракеты - я не могу опубликовать здесь настоящий код)

Дополнительная информация:
В этом случае мы можем быть уверены, что ракеты и яблоки не изменят свои поля позже, поэтому я не слишком обеспокоен случаем «что, если поля в ракете или яблоке изменятся позже».

Answer 1

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

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

Это может показаться большой работой, но приличное объектно-реляционное отображение (например, Hibernate) на самом деле может довольно хорошо обрабатывать иерархии классов для вас и разделять то, что нужно разделить.

Но что бы вы ни делали, не запускайте свою базу данных, пока вы не на 100% уверены, что останется общим и что может измениться.

Answer 2

У вас всегда есть ровно два измерения? Если это так, вам не нужно разбивать таблицу вообще (достаточно иметь одну таблицу с двумя наборами столбцов для двух измерений).

Table: ALL_THE_DATA
Field: ID (int, Primary Key)
Field: aNumber (int)
Field: aDouble (double)
Field: measuredValue1 (double)
Field: standardDeviation1 (double)
Field: calculatedValue1 (double)
Field: weightedError1 (double)
Field: measuredValue2 (double)
Field: standardDeviation2 (double)
Field: calculatedValue2 (double)
Field: weightedError2 (double)

Для необязательных отношений 1: 1 между структурами встраивание дочерней структуры в родительскую таблицу приемлемо с точки зрения дизайна и эффективности.

Однако это затрудняет добавление третьего типа измерения.

Answer 3

Почему бы не создать две таблицы, но сделать так, чтобы они наследовали от общей таблицы измерений?