[support] CCK - Content types with lots of fields

[Jeff Beeman]

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.

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.

Jeff Beeman

On 9/28/07, jp.stacey at torchbox.com <jp.stacey at torchbox.com> wrote:
>
> > Good to know - this is the kind of info I'm looking to gather.  Anyone
> else
> > know of any caveats?
>
> If you've got 30-50 homogeneous fields (so, say, the same field multiple
> times) then I think there are at least two routes available for you:
>
> 1. have a single-input field (or 2-3 inputs) and set it to "Multiple"
> 2. create one big structured CCK data type of 50 fields.
>
> The two will probably have different performance issues because of the way
> they're stored. In the first instance, the table has a single-celled row
> (plus a cell for row id/delta, and a cell for node id) per input field:
> this means that creating the single node involves bringing in 50 rows in
> the SQL.
>
> In the second instance, the data table has a 50-celled row per node: this
> means that any time you want a small bit of the information in a view, CCK
> will prompt the views module to get it all;  my guess is that this would
> slow down the view more, but that the view would be slow in either case if
> you can't avoid grabbing all 50 inputs. It would also improve matters
> because you don't have 50 row IDs and 50 node IDs.
>
> But you might want to benchmark both for your huge data sizes and see
> which is the greater. For such a lot of data you really do want to be
> peeking under the Drupal hood anyway, as there's bound to be SQL
> optimizations you can do. The devel module can help you with creating
> large amounts of dummy content for benchmarking. You could also think
> about rewriting the SQL using hooks if you're feeling really adventurous.
> Probably you could trick your CCK module into returning a restricted
> number of columns in the latter case, when you're in a view mode.
>
> [plug] If you want to know how to create a big internally-structured CCK
> field, I've got an example module that I built recently for storing
> the equivalent of "Amazon book formats" i.e. rich data of
> DxWxH+description+example image, which can then be multiple to show how
> many different formats - paperback, hardback etc. - a book can come in.
>
> http://www.jpstacey.info/blog/2007/09/20/a-complex-cck-module-in-drupal/
>
> The D,W,H,descr and image data are all stored in separate cells, one "book
> format" per row. So for ten nodes of six formats, you have a 5+2-column,
> 60-row table.
>
> Cheers,
> J-P
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20070928/f1ed1a35/attachment.htm