Есть задача дать возможность пользователям создавать и заполнять много форм с произвольными полями и значениями.
В голову пришло только создавать отдельные таблицы под каждую форму. На одном сайте подсказали смотреть в сторону реализации EAV. Покурив литературу, пришёл к выводу, что это действительно простое решение. Осталось всего несколько вопросов:
1. Масштабируемость
2. Скорость выборки.

С первым пока заниматься рано, но хотелось бы выслушать ваши мнения на этот счёт, а вот второе вызывает много вопросов. Хотелось бы протестировать. Например выбрать по 10 разным параметрам из таблицы в 10 млн строк. Остановимся пока на идеальном случае с целыми числами (integer).
Структура таблицы следующая
Нужно создать запрос вроде такого:
SELECT user_id FROM table
LEFT JOIN table ON field_id = 1 and field_value = 3
LEFT JOIN table ON field_id=2 and field_value = 8

В join запросах я не силён, поэтому прошу помощи.

авторЗапросы могут быть и без JOIN, на основе GROUP BY ... HAVING COUNT(*)= ...

А вообще эффективность EAV очень сильно зависит от тонкостей предметной области, от того, какие именно запросы придется выполнять.
Насчёт GROUP BY ... HAVING COUNT(*)= ... спасибо, внесу в список для тестов.

Запросы простые - обрабатывать поиск по множеству разных полей формы, которые заполняют пользователи. Возвращать значение user_id - для которых найдено полное соответствие запросу.


qwerty112нуу, LEFT JOIN, для начала, - тут не приделах, - нужен INNER
а вообще, есть "универсальный" вариант



Да, Кэп, но в этом случае мы получим всех пользователей, у которых есть хоть одно совпадение по любому полю. А нужно получить только те user_id для которых совпадение по всем полям.

Покажите, пожалуйста, свой вариант на INNER.

qwerty112и возвращаясь к "началам"
авторЕсть задача дать возможность пользователям создавать и заполнять много форм с произвольными полями и значениями.
каких, нахрен "форм" ??!
"пользовательский интерфейс" - это что-то "одно", а структура БД - "что-то другое"
никогда нельзя идти на "уродование" структуры БД, из-за ЮИ !! НИКОГДА !

Я что-то писал про UI? Просто образно описал задачу для лучшего понимания предмета обсуждения. Если бы не написал, то первым постом было бы "А зачем это нужно?"

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

qwerty112что такое "заполнять много форм" ?
что ты называешь "формой" ?

может для тебя это что-то "своё", - для меня "форма" - элемент пользовательского интерфейса, не больше, но и не меньше ...
Спасибо за пример с INNER.

Что вы докопались до этих форм, сказано что все данные integer
Даже для абстрактных моделей существуют примеры бытового применения для лучшего "осязания" объекта изучения. Формы в данном случае служат источником данных, они же являются инициатором запроса (поисковая форма). Те же поля из формы соотносятся с Field_id таблицы. И данные введёные в это поле будут записаны в field_value это всё что нужно знать про формы.
И я не пытаюсь интерфейс привязать к Mysql, это абсурд, если знаете пример такого, я бы с интересом взглянул.

javajdbc>> Есть задача дать возможность пользователям создавать и заполнять много форм с произвольными полями и значениями.

для начала : EAV -- а там глядишь, может и приживется

>> В голову пришло только создавать отдельные таблицы под каждую форму.

попробуйте, посоздавайте, в чем проблема протестировать идею?

>> Масштабируемость

уже сказали -- безгранична

>> Скорость выборки.

уже 10 раз сказали -- уточните, что, зачем и с какой скоростью надо.

Вообше, скорость выборки конечно дело серьезное,
но сложность ЕАВ не в этом а в отсутствие "механической"
и "логической" структуры.

Вот вы програмируете на каком-нибудь ООП языке?
Если да, то уберите на это языке способность задавать классы
и оставить бесформеные мешки пар ключ-значение.

Конечно сравнить класс с таблице -- немного притянуто,
но а бы поможет понять проблему.

Да, программирую на C++ и PHP, и понимаю о чём вы. В конце-концов запросы создаются автоматически, в этом нет проблемы. Mysql просто не оптимальный вариант для использования в EAV архитектуре, возможно лучше использовать какое-нибудь MongoDB.

Опробовал с БД в 20 млн записей (Mysql MyISAM). Минимальное время обработки простого запроса. "select user_id where" с одним условием "field_id = x and value_id = y" составило 1 сек, добавил уточняющее поле template_id чтобы выборка была только по отдельному шаблону, время выборки сократилось до 0,13 сек. Подозреваю, что с более сложными запросами inner join или having count не ускорит процесс. Все поля проиндексированы, кеш БД был расширен чтобы вместить весь индекс 750Мб. Железо core i5 16Gb RAM, 250 Gb SSD. Требуется добиться выборки максимум за 0,01 сек, что получилось используя отдельные таблицы (даже меньше 0,001 сек.). Вообщем архитектура EAV не для моих задач, лучше использовать отдельные таблицы под каждый шаблон. EAV в свою очередь можно было бы использовать при условии небольших проектов в таблицах до 1 млн записей или если время ответа не критично. Всем спасибо за участие в обсуждении.

miksoftAlex RengenОпробовал с БД в 20 млн записей (Mysql MyISAM). Минимальное время обработки простого запроса. "select user_id where" с одним условием "field_id = x and value_id = y" составило 1 сек, добавил уточняющее поле template_id чтобы выборка была только по отдельному шаблону, время выборки сократилось до 0,13 сек.Если не будет лень - показывайте подробности, посмотрим что можно сделать.
Мне в свое время удалось получить сравнимый результат на заметно худшем железе.
Даже если результат улучшить в десять раз, это не станет решением, поскольку тестовый запрос на порядок проще того, что должен обрабатываться за сотые доли секунды.