title: Advice on mixing MongoDB w/ MySQL for a web application
body: <p>I have a web application that uses a relational database (MySQL). We're adding a new feature that will allow certain users to dynamically construct 'forms' from a pool of optional form elements and distribute these forms for completion/submission to other users.</p>
  
  <p>The problem lies in storing the completed form submissions. Each form can and will vary in the number and combination of form elements, and with a relational database my options are somewhat limited to dynamically creating a new table to hold the submissions of each form (seems like a bad path to go down) or storing each of the submitted forms as JSON in a TEXT column (losing all useful querying abilities of RDBMSs)</p>
  
  <p>I've never actually used MongoDB in a production project before, but I'm thinking it might be a good idea to use my MySQL relational database to store all the forms created by certain users of my application, and then store all the submissions in MongoDB with each document referencing the UUID of the form in MySQL.</p>
  
  <p>The first disadvantage I can think of with this approach is there's no referential integrity between form submissions and the forms located in MySQL. If I delete a form in MySQL, all of the form submissions will have to be manually deleted (if I want to replicate the 'Cascade' effect)</p>
  
  <p>Would I store all of my form submissions for all of my forms in a single MongoDB collection as individual documents? Any advice is greatly appreciated. :)</p>
  
  <hr>
  
  <p><strong>EDIT 1</strong>
  Based on the documentation here: <a href="http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections" rel="noreferrer">http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections</a></p>
  
  <p>I'm now considering creating a new collection to hold all the submissions from each unique form type.</p>
  
  <hr>
  
  <p><strong>EDIT 2</strong></p>
  
  <p>After some careful consideration and the advice of others I've decided to abandon my dual-database approach to solving this problem in favor of a relational-database schema that I think solves the problem of creating dynamic forms and saving the form submissions in such a way that they're easily query-able for complex reporting.</p>
  
  <p><img src="https://i.stack.imgur.com/SPlXf.png" alt="enter image description here"></p>
  
  <p>Essentially every record in 'forms' represents a unique form that was built by a user. 'forms_fields' has a foreign key that references the form and an enum-type with the options:
  1. checkbox
  2. textfield
  3. textarea
  4. select
  5. multi-select
  6. date</p>
  
  <p>'forms_fields_options' contains all of the 'options' a select field would have.
  With these three tables, users can create customized forms.</p>
  
  <p>When another user fills out &amp; submits the form, a record is created in forms_submissions. For each field, a corresponding record will be created in 'forms_submissions_fields' that references the form submission and the forms_fields_id. The final table, 'forms_submissions_options_multiselect' is essentially a join-table to indicate which options from a multi-select form field the user selected.</p>