3

I building a site that could potentially utilize 20 different content types. The content types are very similar, but may only utilize one or two fields that are unique to that content type, and they would use the same 5 fields with each other. Does having 20 different content types slow the site down? Would it be better to build one content type and display the unique fields on a case by case basis using FAPI or the conditional fields module?

18

The number of content types does not affect the performance of a Drupal site.

Sharing fields among the content types does affect the performance. This is because of the way CCK stores fields.

  • If the field is not shared and allows only one entry, it is stored along with other such fields in a table designated for that content type. That way, all such fields can be loaded in a single query.
  • If the field is shared or allows multiple entries, the field is stored in its own table, making an extra query (or join) per field necessary to load the field.
  • 1
    this should probably be the "correct" answer, the point is that having 20 content types will hardly touch your performance, but using Views to build outputs with shared fields will make your queries less efficient. – David Meister Sep 11 '11 at 12:32
  • I think this is the most correct answer and confirms my initial assumption that the performance hit would take place in a view output. Thanks. – revolt Sep 11 '11 at 17:09
1

I would check out the performance of my database server and queries, web host, modules, and custom code before I would worry about having too many content types.

I have a few sites that have several dozen content types and they are screaming fast. Some of these content-types contain 100,000+ nodes as well.

1

I can't think of a reason why many content types would dramatically affect site performance. Maybe if you build views that display data from many different content types, the queries would be a bit slower, but as Criticguy says, other factors are much more important.

That said... Things to consider before creating a large number of content types, are user experience and maintainability.

I don't know which users are going to create content in your site, but you have to make sure that those users understand the difference between the content types. A large number of types can turn out to be a huge threshold if the end user doesn't know which one he needs to accomplish his task.

For maintainability, it can be a lot of work if you have to alter all content types in a later stage. Something as simple as adding a field or changing the comment settings suddenly becomes a tedious job.

A way to avoid both problems described above, would be to create a single content type which contains all fields, and use taxonomy terms to identify the type of content. To improve the user experience, you could use the Conditional Fields module to hide and show certain fields based on the taxonomy term (or other form values).

0

You could also merge the content types that share most data fields and organize the "differences" into groups inside the manage fields section at Content/Content Types.

If it appears too unwieldy you could use the Vertical Tabs module to clean it all up and keep your users from feeling overwhelmed. http://drupal.org/project/vertical_tabs

I think simplifying the editorial flow for your authors is a good thing.

-1

You are probably using 19 extra content types that you could save in different ways.

The first one, for example, using all the fields in the same, unique, content type, but giving the user the choice to fulfill them or not, depending on your/their needs.

The other is hiding the fields, using the nodeapi or a module like conditional fields: https://drupal.org/project/conditional_fields

Depending on the context, project, requirements, you could find other ways or solutions.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.