Рекомендации по смешиванию MongoDB с MySQL для веб-приложения

Question

У меня есть веб-приложение, которое использует реляционную базу данных (MySQL). Мы добавляем новую функцию, которая позволит определенным пользователям динамически создавать «формы» из пула необязательных элементов формы и распространять эти формы для заполнения / отправки другим пользователям.

Проблема заключается в хранении заполненных отправленных форм. Каждая форма может и будет различаться по количеству и комбинации элементов формы, и с реляционной базой данных мои варианты несколько ограничены динамическим созданием новой таблицы для хранения представлений каждой формы (кажется, плохой путь для перехода) или сохранения каждая из представленных форм в виде JSON в столбце TEXT (теряет все полезные возможности запросов к СУБД)

Я никогда ранее не использовал MongoDB в производственном проекте, но думаю, что было бы неплохо использовать мою реляционную базу данных MySQL для хранения всех форм, созданных определенными пользователями моего приложения, а затем сохранять все представления в MongoDB с каждым документом, ссылающимся на UUID формы в MySQL.

Первый недостаток, который я могу придумать при таком подходе, заключается в отсутствии ссылочной целостности между отправкой форм и формами, расположенными в MySQL. Если я удаляю форму в MySQL, все отправленные формы необходимо будет удалить вручную (если я хочу воспроизвести эффект «Каскад»)

Буду ли я хранить все свои отправленные формы для всех моих форм в одной коллекции MongoDB как отдельные документы? Любые советы высоко ценится. :)

---

РЕДАКТИРОВАТЬ 1 На основании документации здесь: http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

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

---

РЕДАКТИРОВАТЬ 2

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

По сути, каждая запись в «формах» представляет собой уникальную форму, созданную пользователем. 'forms_fields' имеет внешний ключ, который ссылается на форму и тип enum с параметрами: 1. флажок 2. текстовое поле 3. текстовая область 4. выберите 5. мульти-выбор 6. дата

«forms_fields_options» содержит все «опции», которые будет иметь поле выбора. С помощью этих трех таблиц пользователи могут создавать настраиваемые формы.

Когда другой пользователь заполняет и отправляет форму, создается запись в forms_submissions. Для каждого поля будет создана соответствующая запись в «forms_submissions_fields», которая ссылается на отправку формы и forms_fields_id. Последняя таблица 'forms_submissions_options_multiselect', по сути, является объединяющей таблицей, чтобы указать, какие опции из поля множественного выбора формы выбрал пользователь.

Answer 1

Мой коллега недавно провел вебинар по этой теме под названием «Гибридные приложения с MongoDB и RDBMS».Вы можете просмотреть его здесь: http://www.10gen.com/events/hybrid-applications

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

Удачи в вашем приложении!

Answer 2

Это определенно можно сделать в SQL, используя EAV .Так что NoSQL определенно не требуется.

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

... сохранение каждой из представленных форм в виде JSON в столбце TEXT ( потеря всех полезных способностей запросов к СУРБД )

Сколько заявок на форму вы планируете получить?Какой тип запросов вы планируете делать?

Мой опыт работы с MongoDB заключается в том, что он работает очень плохо, когда вы запрашиваете данные, которые не проиндексированы.Кроме того, агрегация обычно выполняется в пакетах с использованием Map / Reduce ( или новой структуры агрегации ).

Если сравнивать сложность выполнения свертки или эффективность выполнения запросов,не ясно, что MongoDB значительно лучше, чем EAV.

Если я удаляю форму в MySQL, все отправленные формы должны быть удалены вручную

СтранноЯ редко видел это как проблему, так как вы, вероятно, никогда не удалите форму в SQL.вы, скорее всего, сделаете логическое удаление и никогда ничего не удалите.Так что это, вероятно, спорный вопрос.

Буду ли я хранить все свои отправленные формы для всех моих форм в одной коллекции MongoDB как отдельные документы?

Опять зависитна сколько форм и заявок вы планируете получить.Если у вас есть много и того, и другого, то использование коллекции / представления будет очень сложно позже осветить.

Честно говоря, я бы использовал одну коллекцию, а затем переопределил поле _id чем-то, что можетразумно использовать в качестве ключа шарда.Здесь можно сыграть несколько причудливых трюков, но это выходит за рамки этой небольшой статьи.

Резюме

Конец дня, вы определенно можете использовать MongoDB для этой проблемы, ноэто не «хоумран».Если вы незнакомы с MongoDB, это, безусловно, справедливый «учебный проект», но вы можете столкнуться с некоторыми препятствиями на пути запросов и агрегирования.

Answer 3

Я думаю, что вы упускаете из виду тот факт, что СУБД позволит таким вещам, как EAV (Entity-Attribute-Value), что ужасно, если вы злоупотребляете им, но может быть полезна при модерации) или объединять таблицы, чтобы создать несколько упорядоченных отношений от одной формы до различных элементов формы.

Я не утверждаю, что СУБД идеально подходит для всего или даже для вашей ситуации, но я знаю, что мне приходилось создавать подобные системы и никогда не приходилось использовать noSQL для их разумной поддержки.

Редактировать: Еще к делу ... сохранение фактических значений полей позволяет выделить еще одно отношение из исходных элементов формы, но если ваш пользовательский интерфейс поддерживает согласованность, вы можете сделать это в общем. Я бы сказал, что если мы рассмотрим, какие решения noSQL допускают конкретные типы запросов на основе значений, которые вам необходимы, вы можете пролить больше света на ваши параметры.