2

I'm looking into enhancing an existing entry form on a Drupal 7 site. We currently are using a single content type and the field API to store all of the data. It already has 46 fields on it, but the business wants hundreds more.

I understand the limitations of MySQL only allowing 61 joins, so I assume that adding 100+ new fields to a single content type using the Field API is out of the question because MySQL will probably crash trying to load the content. (Prove me wrong if you know otherwise)

So my question is, should I create multiple content types which break out the form into a multi-step process, or is there some way to group data from multiple fields into a single table? (I'm thinking of field collections or something similar)

I feel like I have three options:

  1. Field API:
    • Break out the fields across multiple content types
    • Group multiple fields into a single table (field collections? field groups?)
  2. Form API:
    • Implement custom fields and store the data in a custom table
  3. Contrib Module (such as Webform)

Using the form API and custom fields is not completely out of the question, but I'd like to be able to use the Field API if possible since the original form is already using it. I'm also not opposed to switching to webforms or some other method that is better suited for this purpose.

7
  • Honestly, I personally would do this through the FormAPI. I doubt you'll gain any performance through switching to Webform. The only question is where to store it (either in the Drupal db, or a secured secondary db you can access). I would also question why people think they need "hundreds and hundreds" of fields on a form.
    – Kevin
    Nov 10, 2017 at 22:53
  • TBH this really isn't something suited to Drupal, at least in the realm of a node/content type. I don't know what the entry is for, but if it isn't content, it should not be a node. It would be a custom entity type.
    – Kevin
    Nov 10, 2017 at 22:57
  • One possible storage solution too might be a custom table that has JSON data type field storage where you can store JSON objects. It is available in newer versions of MySQL. I am not aware of all of its limitations though, but might ease the storage part of the equation.
    – Kevin
    Nov 10, 2017 at 22:58
  • See: dev.mysql.com/doc/refman/5.7/en/json.html
    – Kevin
    Nov 10, 2017 at 23:27
  • @Kevin Thanks for the advice. The content is ultimately getting displayed to users in various formats through views which is one reason we wanted node content. I'm worried about having to re-invent the wheel by using the form API. I'd have to create each field individually, create custom validation, worry about how to store the data, and then integrate with views. I'm sure there are other things that will need to happen which I can't remember off the top of my head.
    – Keven
    Nov 12, 2017 at 17:00

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.