Не учитывайте модель данных EAV. Легко вводить данные, но сложно выводить данные. Это не масштабируется. У него нет целостности данных. Вы должны сами написать много кода, чтобы делать то, что делает для вас любая СУБД, если вы правильно моделируете свои данные. Попытка использовать СУБД для создания универсальной системы управления формами, способной удовлетворить любые будущие потребности, является примером Intern-Platform Effect antipattern.
(Кстати, если вы используете EAV, не пытайтесь объединить все атрибуты обратно в одну строку. Вы уже прокомментировали, что MySQL имеет ограничение на количество соединений на запрос, но даже если вы можете жить внутри этого, он не работает хорошо. Просто выберите атрибут для каждой строки и разберите его в коде приложения. Зацикливайте строки атрибутов, которые вы выбираете из базы данных, и заполняйте поле вашего объекта полем. Это означает, что для вам написать, но это цена Inner-Platform Effect.)
Если вы хотите хранить данные формы реляционно, каждый атрибут будет идти в своем собственном столбце. Это означает, что вам нужно разработать собственную таблицу для вашей формы (или фактически набор таблиц, если ваши формы поддерживают многозначные поля). Назовите столбцы в соответствии со значением каждого данного поля формы, а не что-то общее, например «checkbox_value». Выберите тип данных в соответствии с потребностями данного поля формы, а не MEDIUMTEXT или VARCHAR одного размера для всех (255).
Если вы хотите хранить данные формы нереляционно, у вас больше гибкости. Вы можете использовать нереляционное хранилище документов, например MongoDB или даже Solr . Вы можете хранить документы, не создавая схему, как в случае реляционной базы данных. Но вы теряете многие структурные преимущества, которые дает вам схема. Вы заканчиваете тем, что пишете больше кода, чтобы «обнаружить» поля документов вместо того, чтобы иметь возможность выводить структуру из схемы. У вас нет ограничений, типов данных или ссылочной целостности.
Кроме того, вы, возможно, уже успешно используете реляционную базу данных для остального управления данными и не можете оправдать одновременное использование двух разных баз данных.
Компромисс между реляционными и нереляционными крайностями заключается в дизайне Serialized LOB с расширением, описанным в Как FriendFeed использует MySQL для хранения данных без схемы . Большая часть ваших данных хранится в традиционных реляционных таблицах. Данные аморфной формы помещаются в один столбец BLOB в некотором формате, который кодирует поля и данные вместе (например, XML, JSON или YAML). Затем для любого поля этих данных, которое вы хотите использовать для поиска, создайте вспомогательную таблицу для индексации этого отдельного поля и ссылки на строки данных формы, где отображается заданное значение в этом соответствующем поле.