3

I'm essentially in the process of learning Craft and in that process have made some great strides.

Today I was examining Craft's tables to see how it was actually storing fields created through Settings-> fields. To my surprise most fields end up as a new column in the content table. To me this seems like a serious flaw as there is a very real limit to the size a table can grow to.

Given this information; what is recommended for developing a site in Craft that needs to have many fields?

If you have an answer I'd appreciate it. Please make it detailed. I'm at a loss with this one. Hopefully there is something I'm missing because if no... Craft may not be the solution I'm looking for. Which would be unfortunate.

Thanks

Improve this question
1
  • 1
    I'd say you're overthinking it. Craft handles hundreds of fields with ease, you should physically put it to the test before stressing out about how it is built. Plus, you can always take advantage of caching your templates if you're really concerned about it.
    – Lindsey D ♦
    Apr 9, 2015 at 7:16

2 Answers 2

Reset to default
5

MySQL has a hard coded limit of 4,096 columns per table, although that can be effectively limited by the data types of columns involved.

Matrix fields get their own tables, so they don't count against the craft_content table.

But yes... if you're planning on having non-Matrix fields in the 2,000 - 4,000 field range, then there's a chance you'll bump into MySQL limitations.

Improve this answer
3
  • Yes but you also have to consider the size of the fields, types of fields, etc. It's not a one dimensional problem. How do you properly index a table like that? I can't imagine a table with even just a few hundred columns would perform well. Again depending on what you're storing. I did notice how matrix fields are saved but not all fields can be matrices, so what's the solution? Do I make some sort of plugin? Seriously just asking. I feel like I'm missing something.
    – user3514
    Apr 9, 2015 at 1:21
  • 3
    I don't think I implied it was a one dimensional problem. We explored many, many database design patterns (including more modular content tables) and have re-written and made changes as necessary because there are trade-offs with each solution. That's the nature of an open-ended CMS and relational databases as far as content modeling is concerned. As of yet, we've seen 0 people run into a problem with the width of that table. And we've seen hundreds of fields in there with hundreds of thousands of rows. If it ever does get to the point of becoming a problem for users, we'll address it then.
    – Brad Bell
    Apr 9, 2015 at 3:12
  • 1
    Originally every section had its own table (way back during private alpha) . We combined it to a single table when we decided to make fields re-usable across multiple sections. In theory, it would still be possible to split them up, & actually create the fields' content columns as they are assigned to sections (so a single field could actually have multiple content columns - one in each section's content table that uses the field), but that would add quite a bit of complexity to the code & it would be harder to do things like sort by a field's value across multiple sections in a single query.
    – Brad Bell
    Apr 9, 2015 at 14:55
5

A huge boon to Craft is the ability to re-use fields across all your content – sections, categories, entry types or even users. The field groups are basically only there to make it easier for you to manage your fields in the CP, and impose no limits on where you can use any one field.

Field re-use means that (at least with a little planning) the number of fields can usually be kept pretty low, even for complex sites.

Improve this answer
6
  • I see what you're saying but then those fields become extremely generic. Also category content is saved in the content table. Lots of stuff is. It's an all purpose dumping ground.
    – user3514
    Apr 9, 2015 at 1:27
  • Sure, and you aren't the first to criticize the design. I guess it's built like that for a reason, and although I agree with the critique I'm also not that concerned about performance on this issue. I won't pretend to be a MySQL expert, but extremely wide tables aren't necessarily slow – it depends a lot on the queries. As for your question, my answer is stated above; reuse fields as much as possible :)
    – Mats Mikkel Rummelhoff
    Apr 9, 2015 at 1:40
  • 1
    ...and consider voting for this feature request, which would make it easier to avoid generic fields.
    – Mats Mikkel Rummelhoff
    Apr 9, 2015 at 1:43
  • 1
    I'm currently working with a site build with over 100 different fields. Some of which are very specific to control content in only one place. But others like "Heading" and "Header Image" are used in 22 of the 30 different Sections/Entry Types. From my experience, it's a surprisingly flexible system in practice.
    – Alex Roper
    Apr 9, 2015 at 10:03
  • What about Craft's caching mechanism. Does that somehow offset a hit on a large table?
    – user3514
    Apr 9, 2015 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy