1

Веб-конфигуратор (для настраиваемых электронных статей) должен сохранять пользовательскую конфигурацию через веб-интерфейс пользователя в базе данных MySQL.Таблица таблиц базы данных: нормализация или нет

Доступные параметры являются статическими, от 10 до 20 различных вариантов.

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

Решение # 1

1 стол:

конфигурации:

  • ID
  • опция1
  • опция2
  • OPTION3
  • т.д.

Решение # 2

2 таблицы и 1 relationTable (смотри ниже)

конфигурации:

  • ID

Варианты:

  • ID
  • имя
  • значение

Это не имеет значения для меня, будет ли это быть unidirectinal OneToMany ассоциации с присоединиться к столу или однонаправленной ManyToOne ассоциации с ForeignKey на стороне опциона.

Вопрос заключается в том, будет ли иметь один стол с примерно 10 до 20 столбцов, каждый для каждого варианта, в конечном счете, необходимо изменить схему базы данных, время от времени, если новые параметры необходимы

ИЛИ

иметь для каждой записи о конфигурации 10 до 20 связанных записей опций.

Таблица конфигураций может вырасти примерно до 2000 конфигураций в месяц => 20000 до 40000 записей опций в месяц.

Время запроса для запроса конфигурации и связанных с ней опций, если таблица параметров имеет более 1.000.000 записей, может быть высокой, правильно (решение № 1)? Это лучший вариант для запроса строки одной таблицы с примерно 20 столбцами (решение № 1)? Возможно, это также является критерием. Есть ли недостатки/плюсы/минусы для любого решения?

+0

IMHO: Если каждый параметр должен присутствовать для каждой конфигурации, тогда решение 1. В противном случае решение 2. Оно просто более стабильно. – Mikey

+0

@Mikey Некоторые параметры могут быть нулевыми, поэтому решение было бы по-прежнему вариантом. Решение 2 более устойчиво к улучшениям, но мне интересно, будут ли запросы неустойчивыми. Я просто отредактирую свой пост и упомянул об этой мысли. Благодаря! –

+0

Итак, некоторые параметры не могут быть обнулены? Эти параметры должны находиться в одной таблице (столбцы с нулевым значением). В другом случае невозможно обеспечить их присутствие. Производительность может быть проблемой, но ее оптимизация: немного рано, и современные базы данных очень хороши в соединениях. – Mikey

ответ

0

Я бы пошел с решением № 2. Я также добавлю кэш-файл в приложение для таблицы options, которая создаст для каждого запрошенного configuration_id объект json (массив, список или любой другой язык, поддерживаемый вашим языком) со всеми запрошенными параметрами, обработанными и готовыми к использованию.

Смежные вопросы