Custom field re-work requirements / suggestions

High level requirements:

1. Support 100-120 custom fields per CiviCRM installation without significant performance degradation.
2. Allow users to create these fields via the UI

Ideas:

1. Retain custom data group user interface. Change the way custom fields are stored at the database level.
2. Create a new UI for "significant" numbers of custom fields. Perhaps define the custom data fields in a csv and then upload that csv to create the appropriate tables, etc.

Cases:

1. Nonprofit has a volunteer application with 20 custom fields. They want to add these custom fields to CiviCRM and create a volunteer application form with CiviCRM profiles, a volunteer directory with listings, and they want to track/edit this volunteer data as a tab in the CRM record.

Look at CCK Approach (Gordon Heywood)

For this you should take a look at what the Drupal CCK guys are doing, which is very similar to custom fields.

Instead of creating a tall and skinny table like the custom fields are now, (and also the Drupal profile module, and flexinode) it actually alters the tables and created much like how people normally create tables.

So instead of a row per custom field per contact (for contact custom data) it is a single row per contact.

It would also make it easier for people to query the custom fields.

Custom Field Groups as Packages (Rob Thorne)

One characteristic of custom data: typically you don't want "just one" – you want a set of fields that are used together. And people who work in the same general kind of application want similar groups of fields.

One mechanism would be to make it possible to create a "package" of fields, stored in the same table where it makes sense, and installing with the tables whatever additional "behavior" these fields need, including hints on editing, validation and so on.

This has two big advantages:

• Fewer joins (since you get all of the fields in the same table)
• A much easier way to "share" a configuration, or to set up multiple installs with the same general configuration (voter files; special demographic data; education info) where the variables have the same names (rather than "custom_44" on one system, "custom_21" on another).

Right now, you pretty much have to write a CiviCRM component to do this, which is not for sissies We could greatly simplify just adding tables, making it relatively easy to develop a new set of fields and distribute them.