Базы данных имеют схемы . Это жесткая структура, которая определяет как характеристики, так и ограничения данных, которые могут быть в нее помещены. Вы не можете делать что-то вроде динамического добавления столбцов и т. Д. Без существенного влияния на целостность базы данных.
В настоящих реляционных базах данных (SQL Server, MySQL, Postgresql и т. Д.). Такие изменения категорически запрещены. Однако некоторые менее жесткие решения NoSQL либо не содержат схем, либо имеют гибкие схемы и позволят вам просто начать отслеживать новую точку данных без предварительного изменения структуры базы данных. Даже тогда, однако, целостность данных становится серьезной проблемой, и вы можете в конечном итоге потерять весь свой набор данных, если будете делать такие вещи волей-неволей.
Короче говоря, нет никакой "динамики" в отношении баз данных. Даже в решениях NoSQL от вас ожидают, что вы спланируете структуру данных заранее, и если вы не сделаете это, это приведет к несоответствиям в данных, которые могут полностью свести на нет их полезность.
Ваша лучшая ставка для чего-то подобного описанному требованию - на самом деле иметь стол Features. В простейшей форме это может быть просто строковый столбец для имени и внешнего ключа или просто столбец ссылок на идентификаторы (в зависимости от того, реляционный он или нет) обратно к продукту, с которым он связан. Вам также понадобится первичный ключ, который может быть либо составной частью имени и идентификатора продукта (по сути, делая комбинацию уникальной), либо вам может потребоваться столбец с действительным типом идентификации.
Ключ с данными, как правило, является обобщением. Ничто не является полностью уникальным, а просто вариации других вещей. Сведите ваши данные к наименее распространенным знаменателям, чтобы определить действительную схему. Затем, где есть выбросы, вы можете выбрать менее жесткую стратегию, как описано выше.