Also note that its been reported that sites with both many (like 40, 50 ?) cck fields *and* Views module can result in high memory consumption. Still an open issue... Bill Fitzgerald a ecrit le 27/09/2007 17:49:

Hello, Jeff,

Three options I'd look at, in this order:

http://drupal.org/project/cck_fieldgroup_tabs

http://drupal.org/project/wizard -- this will need some development attention, but would be an amazing module to have working cleanly

http://drupal.org/project/pageroute -- this might not be your exact use case, because this provides a path to create multiple nodes.

Cheers,

Bill

Jeff Beeman wrote:

...

Does anyone have any experience or comments on creating content types with CCK that have lots of fields? I am considering it's use in a project where content types would need 30, 40, maybe even 50 fields.

If performance isn't an issue, what about UI? Are there ways to break node submission into several pages? The groups would be at least a good start for node submission, but it'd be nice in this case if it were a little more "wizard"-ish.

Jeff Beeman

Depending on how the solutions are developed the back button may behave differently. Multi-part forms have this trouble in Drupal because they use the "op" action to tell what page you're on. Pageroute is likely to behave better with the back button than some others. I'd recommend being careful to test back/forward button behaviors with these solutions. Dave ________________________________ From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Jeff Beeman Sent: Thursday, September 27, 2007 12:32 PM To: support@drupal.org Subject: Re: [support] CCK - Content types with lots of fields Good to know - this is the kind of info I'm looking to gather. Anyone else know of any caveats? Jeff On 9/27/07, Yves Chedemois < yched.drupal@free.fr <mailto:yched.drupal@free.fr> > wrote: Also note that its been reported that sites with both many (like 40, 50 ?) cck fields *and* Views module can result in high memory consumption. Still an open issue... Bill Fitzgerald a ecrit le 27/09/2007 17:49:

Hello, Jeff,

Three options I'd look at, in this order:

http://drupal.org/project/cck_fieldgroup_tabs

http://drupal.org/project/wizard -- this will need some development attention, but would be an amazing module to have working cleanly

http://drupal.org/project/pageroute -- this might not be your exact use case, because this provides a path to create multiple nodes.

Cheers,

Bill

Jeff Beeman wrote:

...

Does anyone have any experience or comments on creating content types with CCK that have lots of fields? I am considering it's use in a project where content types would need 30, 40, maybe even 50 fields.

If performance isn't an issue, what about UI? Are there ways to break node submission into several pages? The groups would be at least a good start for node submission, but it'd be nice in this case if it were a little more "wizard"-ish.

Jeff Beeman

-- [ Drupal support list | http://lists.drupal.org/ ]

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@torchbox.com <jp.stacey@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/ ]