Я создаю какое-то приложение, вовлекает учебные программы. моя проблема такая,
Тренировка может быть простой:
3 sets of 45 push ups. поэтому я бы просто создал 2 поля, sets / count
НО тренировка может быть также:
45 minutes run, 3 sets of 45 pushups, 2 minutes of rope jumping, 150 meter swimming.
поэтому мне нужно создать одну таблицу, которая будет знать, как хранить данные, так как она меняет структуру, а позже я могу перевести ее на реальные данные на gui.
как я могу сделать это эффективно и мудро?
редактировать:
Чтобы сделать это немного ясно, я хочу указать каждой тренировке, что Ive сделал в ней. поэтому одна тренировка может быть: 3 комплекта, во-первых: 45 отжиманий второй: 32 отжимания третьего: 30 отжиманий
и еще одна тренировка может быть: 3 набора отжиманий: во-первых: 45 отжиманий второго: 32 отжимания третьего: 30 отжиманий, а также 2 минуты прыгающей веревки 150 метров плавания
данные не являются консистенциями, один набор может быть числом push ups, следующий может быть временной и т. д.
Я бы сказал, что это требует отношения 1: n, где есть таблица мастеров «тренировок» и одна унифицированная таблица «компонентов», которая содержит все действия тренировки.
У вас будут основные workouts столе:
id int participant varchar(255) date datetime ...... any other workout related data
Затем дочерние таблицы workout_components :
workout_id int // Which workout this belongs to tabindex int // Which sorting order this component has in the list repeat int // Number of repetitions (eg 3 sets) quantity int // eg 45 push-ups or 150 meters of cycling quentity_unit varchar // eg minutes or laps activity varchar // push-ups, cycling .....
примерное значение будет выглядеть так:
таблица тренировки:
id participant date 1 Harry Miller 2010-08-21
таблица workout_components:
workout_id tabindex repeat quantity quantity_unit activity 1 1 3 45 pcs pushups 1 2 1 2 minutes rope-jumping
Преимущества:
Не ограничиваясь конкретными видами деятельности
Легко запросить – на каждый вопрос, связанный с тем, как получить что-то из этой структуры данных, уже был дан ответ на SO
Мероприятия могут быть свободно добавлены к каждой тренировке
Вы можете создать таблицу со следующими столбцами: WorkoutType | Наборы | Значение | Тип значения . Таким образом, вы можете хранить как
---------------------------------- WorkoutType | Sets | Value | ValueType ---------------------------------- Pushups | 3 | 45 | nos Run | null | 45 | minutes Rope Jumping | null | 2 | minutes Swimming | null | 150 | meter
Вы можете рассмотреть схему базы данных, такую как:
CREATE TABLE workouts ( workout_id int, user_id int, PRIMARY KEY (workout_id) ) ENGINE=INNODB; CREATE TABLE sessions_pushups ( started datetime, workout_id int, number int, PRIMARY KEY (started, workout_id), FOREIGN KEY (workout_id) REFERENCES workouts (workout_id) ) ENGINE=INNODB; CREATE TABLE sessions_rope_jumping ( started datetime, workout_id int, duration_minutes int, PRIMARY KEY (started, workout_id), FOREIGN KEY (workout_id) REFERENCES workouts (workout_id) ) ENGINE=INNODB; CREATE TABLE sessions_swimming ( started datetime, workout_id int, meters int, PRIMARY KEY (started, workout_id), FOREIGN KEY (workout_id) REFERENCES workouts (workout_id) ) ENGINE=INNODB;
Это позволяет вам выполнять сложные тренировки, которые не соответствуют схеме предыдущих тренировок. У вас может быть что-то подобное очень легко:
CREATE TABLE sessions_triathlon ( started datetime, workout_id int, swimming_meters int, cycling_meters int, running_meters int, duration_minutes int, PRIMARY KEY (started, workout_id), FOREIGN KEY (workout_id) REFERENCES workouts (workout_id) ) ENGINE=INNODB;
Мартин Фаулер называет вышеупомянутую модель «Наследование бетонных таблиц» в своей книге « Архитектура корпоративных приложений» . Билл Карвин также описывает эту модель в своей книге SQL Antipattens в главе Entity-Attribute-Value. Он также описывает недостатки в выборе модели EAV для решения такого сценария.
С другой стороны, если вам нужна полная гибкость схемы, вы можете рассмотреть другие решения NoSQL вместо MySQL. Обычно эти хранилища данных обычно не требуют схем фиксированной таблицы.