Table design for Custom Fields

[theprofoundgeek]

Hello,

I was working with the custom field and came across this table :

vicidial_lists_fields (
field_id INT(9) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
list_id BIGINT(14) UNSIGNED NOT NULL DEFAULT '0',
field_label VARCHAR(50),
field_name VARCHAR(1000),
field_description VARCHAR(100),
field_rank SMALLINT(5),
field_help VARCHAR(1000),
field_type ENUM('TEXT','AREA','SELECT','MULTI','RADIO','CHECKBOX','DATE','TIME') default 'TEXT',
field_options VARCHAR(5000),
field_size SMALLINT(5),
field_max SMALLINT(5),
field_default VARCHAR(255),
field_cost SMALLINT(5),
field_required ENUM('Y','N') default 'N',
name_position ENUM('LEFT','TOP') default 'LEFT',
multi_position ENUM('HORIZONTAL','VERTICAL') default 'HORIZONTAL',
field_order SMALLINT(5) default '1'
);

Here, as per my understanding field_options VARCHAR(5000), is used to store the options of fields types with multiple options such as checkbox. Isn't it a bad way to store it this way?

Would creating a new table named vicidial_lists_fields_options with :

field_id | Option

would be a better way to do this? Are there any particular reasons to store options in a single string?

[mflorell]

It seems to work pretty well actually, and it's a lot faster than sticking up to hundreds of options in separate records in a separate table. We actually did a ton of testing on just about every aspect of custom fields to ensure it could stand up to hundreds of agents and millions of records and what we created two years ago has stood up very well.