Imo, normalizing the db as you said wouldn’t be much of a difference than how it already is. You’d just add an additional join to the mix, which is a known performance hit.
Unless your getting thousands of emails a day, you shouldn’t run into issues in the long run. If you are getting that many contacts then you are probably dealing with a high performing site and you’d hopefully have something in place to manage that much email.
Is there are reason you want the db normalized?
My rationale on this is to favor simplicity, flexibility and maintainability over what I expect to be negligible performance optimizations. The current schema supports any form even after there are submissions and the author decides to change the form (adding/removing/changing fields) and continuing to allow submissions. There is no need to have code to create specific tables with columns to explicitly match fields in the form definition and to change them to reflect changes in CF7 form definitions that may later occur. Not only is this whole set of administrative logic avoided, the plugin code consequently requires minimal knowledge of CF7 code and its data structures, thereby making it unlikely to break due to unexpected changes in future revisions of CF7.
I have to disagree on the term “negligible” performance optimization because this (making the data load into a sql table in a usual and logical way – a column for each value and a row for each closely related set of values)would make it much easier to manage larger sets of data, for example company questionnaire. In this way, the plug-in is only usable for small sets of data that have to be controlled and managed personally using the dashboard.
For example, my intention was to load data generated by the web forms directly and automatically from the website sql table into the FileMaker Pro database table so the people in the office (working with FileMaker Pro) can use it as they come – strait away, like they use the data from the user login form. With this system this is not possible as there is no Unique Identifier for the data, they appear all around. What we have to do then is employ somebody to export the data into an Excel sheet (or some other format allowed) and then import it back in a proper order.This is also not perfect as the data appears again in this sheet “all around”. So, basically this simple CF code will really complicate the day in the office for any company that would receive more then 30-50 enquiries.
With all this in mind, from the point of view of a database administrator, the plug-in is not functional as it is. Is there an alternative for professional use with WordPress?
Given that:
1. You have a need for direct interaction with a database table whose table definition reflects your form
2. You have performance concerns for large data sets
3. I don’t intend to re-write the plugin and add lots of additional table management code
4. You don’t mind NOT using the plugin admin page for viewing data that you might load on the back-end
Then perhaps I accommodate this by providing a place for you to inject your own SQL insert statement. Image there is an Admin panel where you specify the form name and a parametrized SQL Insert statement. The plugin then uses that to additionally insert data into your table (perhaps a table directly used by FileMaker Pro?). You create/manage that table, so you can index it, etc.
This post I made on how to create a pivot query to get your data directly from the DB may be of interest to anyone following this discussion.
