Нормализованная структура таблицы в MySql ... Вроде? - PullRequest
Новая
       8

Нормализованная структура таблицы в MySql ... Вроде?

0 голосов
/ 26 февраля 2012

Мне интересно, что думают о следующих структурах таблиц для MySQL.

У меня есть взаимосвязь между упражнениями и параметрами упражнений, где одно упражнение может иметь несколько параметров.

Например,у упражнения «приседания» могут быть параметры «наборы» и «повторения».

Все упражнения начинаются с набора параметров по умолчанию.Например: подходы, повторения, вес, удержание и отдых.

Этот список полностью настраиваемый.Пользователи могут добавлять параметры, удалять параметры или переименовывать их для каждого упражнения в базе данных.

Чтобы выразить эту связь, я имею следующую структуру один-ко-многим: 

TABLE exercises
ID
Name

Table exerciseParameters
ID
exerciseID -> exercises(ID)
Name

Что касается меня, так это то, что я замечаю, что, хотя пользователи имеют возможность переименовывать / настраивать параметры, большую часть времени они этого не делают.Так что моя таблица exercParameters немного пополняется повторяющимися словами, такими как «Sets» и «Reps».

Есть ли лучший способ организовать что-то подобное, чтобы избежать такого большого количества повторений?(Помните, что имена параметров должны быть настраиваемыми пользователем. Например, «Reps» может быть изменен пользователем на «Hard Reps».) (Или я делаю крупную сделку из ничего, и этоок, как есть?)

Заранее спасибо за помощь.

Ответы [ 2 ]

3 голосов
/ 26 февраля 2012

Если вы не имеете дело с миллионами строк, я бы оставил структуру такой, какая она есть. Это просто и легко сделать запрос.

Если вы имеете дело с миллионами строк и у вас есть измеренное влияние на хранение и вы считаете его неприемлемым, то у вас есть несколько вариантов (не обязательно взаимоисключающих):

Не хранить значения по умолчанию

Если параметр отсутствует в exerciseParameters, просто предположите, что он имеет значение по умолчанию. Фактические значения по умолчанию могут храниться в отдельной таблице или вне базы данных (в зависимости от ваших запросов).

  • Если пользователь изменит параметр по умолчанию, сохраните его в exerciseParameters.
  • Если пользователь удаляет параметр по умолчанию, представьте его как строку exerciseParameters, содержащую значение NULL.
  • Если пользователь восстанавливает параметр по умолчанию в его исходное значение, удалите его из exerciseParameters.

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

Реорганизовать модель данных

Таким образом, имена (и значения) сохраняются только один раз, что делает повторы дешевле. Например:

enter image description here

ParameterNameID и ParameterValueID являются целыми числами , поэтому каждое повторение в exerciseParameters намного дешевле (с точки зрения хранения), чем если бы они были строками. OTOH, вы теряете простоту и потенциально платите за запрос производительности (требуется больше JOIN).

Использовать другую СУБД

Тот, который поддерживает кластеризацию и сжатие передовых индексов (например, таблица Oracle ORGANIZATION INDEX COMPRESS может значительно уменьшить влияние хранения повторных значений).

0 голосов
/ 26 февраля 2012

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

...