Нарушение 1-й нормальной формы, это нормально для моей цели?

Question

Итак, я делаю текущий журнал, и тренировки хранятся в виде записей в таблице.Для каждой тренировки пользователь может добавлять интервалы (которые состоят из времени и расстояния), поэтому у меня есть такой массив:

[workout] =>
    [description] =>
    [comments] =>
    ...
    [intervals] =>
        [0] =>
            [distance] => 200m
            [time] => 32
        [1] =>
            [distance] => 400m
            [time] => 65
        ...

Я действительно испытываю желание бросить массив «интервалы» вserialize () или json_encode () и поместите его в поле «интервалы» в моей таблице, однако это нарушает принципы хорошего проектирования баз данных (о которых, кстати, я почти ничего не знаю).

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

Answer 1

То, что значения являются числовыми, подсказывает мне, что в конечном итоге вы обнаружите необходимость выполнять какую-то математическую функцию против них, такую ​​как среднее или стандартное отклонение.Таким образом, вам лучше хранить их таким образом, чтобы вы могли использовать SQL для манипулирования ими, а не перетаскивать его обратно на язык программирования.

Теперь это не обязательно означает, что вы должны использовать другую таблицу.Но это, безусловно, самый простой, стандартизированный способ сделать это.Но если вы действительно хотите сохранить их вместе с другими данными в одной таблице (то есть в таблице workout), используйте XML.

Я говорю XML, потому что большинство механизмов баз данных предлагают нестандартный SQL для запроса этих значений.У SQL Server, Oracle и MySQL есть способы сделать это.Сериализация связывает вас с любым языком программирования, с которым вы работаете (например, Java).В JSON отсутствует поддержка AFAIK для SQL, поэтому вам все еще нужно перенести его обратно на язык программирования, чтобы манипулировать осмысленным образом.

Answer 2

Я думаю, что это плохая идея.Например, насколько большим должно быть поле интервалов?Если разбить это на две таблицы, так как это выглядит как отношение «один ко многим», вам не нужно будет учитывать искусственное ограничение размера на число интервалов.Никогда не нужно запрашивать на основе интервалов, вы можете позже передумать и найти случаи, когда вы действительно хотите это сделать.Зачем ограничивать свои способности и искусственно денормировать этот конкретный случай.Создание двух таблиц не так уж и сложно.Кроме того, вы всегда можете присоединиться к ним, чтобы рассматривать их как единый логический набор данных для запросов и обладать лучшим из обоих миров.

Answer 3

Если вы никогда не планируете разлагать данные, которые вы храните, для поиска по ним или для чтения / обновления / удаления / вставки отдельных значений, я бы просто добавил их и рассматривал как единое целое для ваших целей.1001 *

Строки могут быть разложены на отдельные символы, но никто не утверждает, что они нарушают 1NF AFAIK.