Storing email lists with a variable number of fields - mysql

Question

I am looking to allow my users to store their email lists and I am using MySQL.
I want to allow users to decide what fields their email list may have. eg. Name, Email, Location, Birthday
Each user may want different fields and each list may have different fields to each other.
I'm really stuck as to how I should structure my databases to allow for this. Any help would be appreciated.

Answer 1

Since the number of fields and the types of fields are possibly unknown, and could change depending on the user, it might not make sense to hard code them as columns. Instead, I would recommend that you use a key value pair approach here. First define a table email_fields looking something like this:
user_id | id | field
1 | 1 | Name
1 | 2 | Email
1 | 3 | Location
1 | 4 | Birthday
Above user 1 has configured his email lists to have four fields, which are the ones you gave as an example in your question. Adding more fields for this user, or adding more users, just means adding more records to this table, without changing the actual columns.
Then, in another table email_lists you would store the actual metadata for email address and user:
id | user_id | field_id | value
1 | 1 | 1 | Sam Plan
1 | 1 | 2 | sam.plan#somewhere.com
1 | 1 | 3 | Gonesville, AL
1 | 1 | 4 | 1967-03-28
In other words, the basic idea is that every email, for every user, would be represented a set of records corresponding to a bunch of key value pairs.

Answer 2

I am looking to allow my users to store their email lists and I am using MySQL.
This means that a given user may have more than one email list.
So the appropriate table for storing the email lists should be like this one:
+---------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| user_id | int(10) unsigned | NO | | NULL | |
| title | varchar(255) | NO | | NULL | |
+---------+------------------+------+-----+---------+----------------+
Each user may want different fields and each list may have different fields to each other.
The fields will be text or numerical. The user could create his own fields
+---------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| email_list_id | int(10) unsigned | NO | | NULL | |
| field | varchar(255) | NO | | NULL | |
| value | longtext | YES | | NULL | |
+---------------+------------------+------+-----+---------+----------------+
Here is the SQL query to create those tables:
CREATE TABLE `email_list` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`user_id` int unsigned NOT NULL,
`title` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `email_list_data` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`email_list_id` int unsigned NOT NULL,
`field` varchar(255) NOT NULL,
`value` longtext DEFAULT NULL,
PRIMARY KEY (`id`)
);
In another approach, you will use a different table for storing the fields and another one for storing the values.
CREATE TABLE `email_list` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`user_id` int unsigned NOT NULL,
`title` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `email_list_fields` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`email_list_id` int unsigned NOT NULL,
`field` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `email_list_field_values` (
`email_list_id` int unsigned NOT NULL,
`field_id` int unsigned NOT NULL,
`field_value` longtext DEFAULT ''
);

Answer 3

The other answers remove around metadata. This is great, though it isn't meant for large amounts of data or relationships based on a "record" because there would be no Contact model. You would return 30 records if there were 30 fields specified for the contacts in the list.
It would take 2 parts that are highly complicated to implement, but would be more structured in the end.
1) Tenant DB Structure
There are some tutorials out there that can help with this. Essentially, you would have 1 master database that stores your teams, etc. Then, each of your teams would get their own database. We have a project that implements this structure and it works well. You can be connected to both the main and the specific tenant database at the same time.
2) Generating migration files
I have never done this part before, but I assume it is possible..
Try making a flexible schema-file builder. You can execute system commands via PHP to save a file you generated into a directory structured on your teams, such as /migrations/teams/1/37284_user_submitted_migration or something like that.
Execute
You can then run the artisan migration command on that specific file, for that specific tenant database (use the Artisan::run() facade helper). Each of your teams could have whatever structure they wish, as if you had built it for them.
This can all be executed within the same job.