Thread

I think I recall someone way back addressing this issue, but has anyone ever wondered about the way EE stores data for custom fields. It’s all stored in one table. Every entry has a column for all the custom fields used across all weblogs.

With the ease at which you can create custom fields for custom applications, I wonder who’s pushing the limits. I’ve never had more than around 40 or so, but I suspect there are others with easily more than 100 custom fields.

Performance has never been a problem for my sites ( all < 1000 pages), but still ... having all that extra space for each record makes me wonder. Is there ultimately a performance price for this model? 2000, 3000 pages with 100 custom fields, etc ...

A similar question with replies by both Rick and I.

Nice explanation, thanks. So you’ve stuck with the model since ... non-issue at this point, I guess?

The other issue I’ve thought about is how you can’t associate custom fields to different field groups, perhaps for sake of simplicity under the hood. Body, Summary, for example, these are custom fields, but relatively standard so they just get duplicated over and over.

We have stuck with this approach because of the three approaches we have considered, it is the best all around solution.

That is not an issue relating to having all of the fields in one table, but more of the fact that we would have to rewrite a great amount of count and do a great deal of testing to make sure it all worked.  We did not feel like tackling that challenge during a point point release.

Hi,

I might guess that the major issue associated with your current database design and physical SQL database implementation, is performance optimization for queries that might need to search custom fields. While performance might be adequate for any query that uses the current indexed structure, it might degrade very rapidly (e.g. full table scans), if the number of rows in the table becomes very large. For most blogs, my guess, this is not an issue, however, it may become a problem in forums, or anywhere there might be lots of entries being created. So this may pose a scalability issue for larger organizations with thousands of potential users. However, this is probably not a major issue for my site, which may have only a few thousand rows that need to be scanned - or so I guess.

I would be interested in any comments or insight into SQL query optimization and performance issues since I am considering EE for a redesign of my site. Thanks.

Rich