Thanks, everyone, for all the great feedback. I think I may go ahead and just create some test cases, fill them with data from the devel module and test performance from there. The results could be beneficial for everyone.
<br><br>Regarding multiple vs. single input fields; I imagine we will have a few fields in each case that contain multiples, but the vast majority will be distinct fields.<br><br>Jeff Beeman<br><br><div><span class="gmail_quote">
On 9/28/07, <b class="gmail_sendername"><a href="mailto:jp.stacey@torchbox.com">jp.stacey@torchbox.com</a></b> <<a href="mailto:jp.stacey@torchbox.com">jp.stacey@torchbox.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Good to know - this is the kind of info I'm looking to gather. Anyone else<br>> know of any caveats?<br><br>If you've got 30-50 homogeneous fields (so, say, the same field multiple<br>times) then I think there are at least two routes available for you:
<br><br> 1. have a single-input field (or 2-3 inputs) and set it to "Multiple"<br> 2. create one big structured CCK data type of 50 fields.<br><br>The two will probably have different performance issues because of the way
<br>they're stored. In the first instance, the table has a single-celled row<br>(plus a cell for row id/delta, and a cell for node id) per input field:<br>this means that creating the single node involves bringing in 50 rows in
<br>the SQL.<br><br>In the second instance, the data table has a 50-celled row per node: this<br>means that any time you want a small bit of the information in a view, CCK<br>will prompt the views module to get it all; my guess is that this would
<br>slow down the view more, but that the view would be slow in either case if<br>you can't avoid grabbing all 50 inputs. It would also improve matters<br>because you don't have 50 row IDs and 50 node IDs.<br><br>
But you might want to benchmark both for your huge data sizes and see<br>which is the greater. For such a lot of data you really do want to be<br>peeking under the Drupal hood anyway, as there's bound to be SQL<br>optimizations you can do. The devel module can help you with creating
<br>large amounts of dummy content for benchmarking. You could also think<br>about rewriting the SQL using hooks if you're feeling really adventurous.<br>Probably you could trick your CCK module into returning a restricted
<br>number of columns in the latter case, when you're in a view mode.<br><br>[plug] If you want to know how to create a big internally-structured CCK<br>field, I've got an example module that I built recently for storing
<br>the equivalent of "Amazon book formats" i.e. rich data of<br>DxWxH+description+example image, which can then be multiple to show how<br>many different formats - paperback, hardback etc. - a book can come in.
<br><br><a href="http://www.jpstacey.info/blog/2007/09/20/a-complex-cck-module-in-drupal/">http://www.jpstacey.info/blog/2007/09/20/a-complex-cck-module-in-drupal/</a><br><br>The D,W,H,descr and image data are all stored in separate cells, one "book
<br>format" per row. So for ten nodes of six formats, you have a 5+2-column,<br>60-row table.<br><br>Cheers,<br>J-P<br>--<br>[ Drupal support list | <a href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]<br>
</blockquote></div><br>