Akina,

3 пожалуй маловато будет. ТС-у рекомендую почитать про EAV (Тенцер, 2004) или "продольное хранение" как мы когда-то такое называли в конце 90-х.. тут одна и версий.

Ну и таки да, придется выдать в csv, считать, разобрать по группам, и правильно воткнуть куда надо в правильном порядке, проставляя иденты вставленного поперед .. надеюсь понятно выразился. :)

Vasiliy_Kashkin,

Такой вариант хранения имеет как свои достоинства, так и недостатки. "Модное/Устаревшее" - это пожалуйста на женский подиум, там оно больше применимо к рюшечкам, вырезам, материалу декольте, кмк.

Достоинства:
1. Возможность динамического изменения набора свойств сущности произвольным способом.
2. Возможность экономного хранения повторяющихся наборов значений, в т.ч. и для разных сущностей.

Недостатки:
1. Сложная организация эффективных запросов. Практически всегда это джойн с группировками и having.
2. Снижение скорости чтения примерно в 2 раза, в сравнении с плоскими таблицами и это при высокооптимизированных запросах. В реале при традиционных подходах потери могут достигать и 10 раз.
3. Требует специалиста СУБД крайне высокого уровня. Это даже не "эксперт" .. в общем, надо уметь готовить.. :)
4. Потеря контроля целостности встроенными средствами в реляционную модель. Тока ручками.

Часто применяется в крупных развесистых рабочих проектах, достаточно широко. Ну, скажем мне попададется регулярно, особенно в "автопроме", где параметров - многие тыщи..

Есть проекты, где работает "смешанная модель", в автоматическом режиме. Новое создается в EAV, с подсчетом статистики выборок по параметрам, при достижении определенного порога потребности и стабильности хранения - переводится в плоскую часть сущности, таблица которой перестраивается динамически.

В целом, EAV это попытка уйти от недостатков реляционной модели .. мир сложнее, проще и интересней чем "реляция" .. :) Таких попыток много. Если решение задачи не может обойтись без EAV, кмк, стоит смотреть в сторону mumps, которое теперь модно зовется Cache кажется. :)

P.S. дополнил.

Akina,

Csv-то можно трогать и напрямую .. тока выдрать из плоской таблицы нужное и перегруппировать в продольный набор .. надо чутка попотеть. Ну и вставка будет строго последовательной: сначала воткнуть сущности и свойства и тока потом формировать значения, проставляя связанные индексы.
Да, свойства тупо не вставишь, их надо мерджить на одно название для разных сущностей, иначе вся прелесть EAV пойдет лесом.

Они не кривые. Это просто продольное хранение .. не реляционная модель в реляционной СУБД. :)

ТС-у
В целом, модные "оконные функции" последних версий Мускуля и его форков кмк могут сильно облегчить решение задачи. Но это не точно, не гонял на практике. Сам только осваиваюсь с ними и то "по мере возникновения задач".. :)

В вашу таблицу описания свойств fieldsMeta надо бы добавить ещё "тип значения" {булево, перечисление, целое, текст, дата} для автоподстановки нужного поля(или даже отдельной таблицы значений) этого типа в запрос. Это усложнит сами запросы, но позволит поднять скорость выборок, т.к. сравнение разных типов с текстовым хранением самих значений идет крайне медленно.

Соответственно, добавить поля в таблицу значений. Да, она будет очень рыхлой, но сейчас это не узкое место. Ничего лишнего на дисках не будет, как понимаю современную организацию InnoDb и его последователей.

Сами значения перед вставкой стоит проверять на "дубликатность" и не хранить в таблице значений "одно и тоже" для разных свойств сущностей. Это как раз и есть "второе достоинство", но требует проработки части "таблица значений" тщательно. Хорошо сворачиваются таким способом особенно - даты.

Можно пойти средним путем: выписать заведомо известные свойства (фасовка, упаковка, цвет, вкус и т.д.) в плоскую часть сущностей, а дополнения оставить в продольной части.

Свойства стоит "группировать" (организовать в виде дерева), т.к. часто они представляют из себя иерархию..

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

В общем, проектирование БД с продольным хранением задача ещё та, не для "курсовика". :)

"не сильно сложно" .. Вам? Охотно верю. :)