How many content types are "too many"?

By ExTexan on 24 Feb 2015 at 23:24 UTC

I have in mind a series of racing-sim-related sites and would like to run them with a single Drupal 7 code base (no problem with that, I know), and with a single database through the use of the Domain Access module. I am concerned about the number of content types I'll end up with - and, by extension, the number of tables I'll have because of all the fields added to those content types.

One site is live already, and has the following content types:

Article
Basic page
Forum topic
Poll
Advanced poll
Product
Payment
...plus eleven content types that are specific to the racing features.

As I add more domains for additional racing sims, I will probably need as many "additional" content types for each new domain as I have above (the "eleven additional", that is). At this point, the plans are for a total of at least eight racing sites. If there are 10 or 11 content types for each one, that's more than 80, plus the ones listed above.

The live site currently has 565 tables, of which 190 are for fields added to the aforementioned content types - x2 because of revision tables, making a total of 380.

So my questions are:

1) What is a realistic limit for the numbers of content types, fields, and tables in a Drupal 7 installation (using MySQL).

2) Can the Domain Access module handle all this?

3) I could get by with only sharing the user table(s). Is there an easy way to accomplish that, and would it be better than using Domain Access and having everything in one database?

TIA for any help you can offer.

Comments

1) What is a realistic limit

John_B commented 26 February 2015 at 00:04

1) What is a realistic limit for the numbers of content types, fields, and tables in a Drupal 7 installation (using MySQL).

100+ content types should be fine, and probably many more. If the site gets slow, just allocate more resources to hosting. Of course a lot of database traffic means spending more time, money and skill on hosting. However, the actual cost depends on the type as well as the number of queries, so there is no general formula relating how much you need to spend to the number of tables in your db.

2) Can the Domain Access module handle all this?

yes

3) I could get by with only sharing the user table(s). Is there an easy way to accomplish that, and would it be better than using Domain Access and having everything in one database?

You could have multiple sites with single sign on using https://www.drupal.org/project/bakery

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

-=o=-

ryivhnn commented 26 February 2015 at 02:28

Assuming that you have the resources and things to handle everything else, "too many" is probably when it starts becoming complicated to handle and/or you find you're not using some of them :)

works at bekandloz | plays at technonaturalist

I could understand needing 11

Jaypan commented 26 February 2015 at 03:51

I could understand needing 11-12 new nodes on a given site, but needing 11-12 new content types on a site doesn't sound right. Can you give examples of this, and why you can't just use existing content types with different fields?

Thanks for your feedback...

ExTexan commented 26 February 2015 at 23:48

@John_B,

Thanks for that detailed answer. That is very helpful information.

I took a look at the bakery module you recommended. Unfortunately, it seems to require sites to all be of the same base domain name - which mine aren't. I realize it also says it would work for any sites "that implement the same web cookie, xmlrpc, and POST methods", but I'd rather not open up that can of worms. In any case, your answer about Domain Access being able to handle my sites eliminates the need to look at other options.

@Jaypan,

I'm not sure what you mean by "...why you can't just use existing content types with different fields?" It seems to me the whole purpose of having the ability to create different content types is when you have different fields for each one. Or am I missing something in your question?

To elaborate on what I have in the current live site... As I said, it is for a racing game app, so it has the following content types and relationships:

Circuits - All tracks (with various circuit layouts) in the game.
Cars - All cars available in the game
-----with several FieldCollection fields for upgrade stages (engine, drivetrain, etc.)

MyGarage - Allows members to keep track of their own fleet of cars (in the game)
-----EntityRef to Cars

Series - The highest-level grouping of events in the game
Tiers - The middle-level grouping of events in the game
-----EntityRef to Series
-----EntityRef to Cars
Events - All events in the game
-----EntityRef to Tiers
-----EntityRef to Circuits

Ultimate Leaderboard - Allows members to enter leaderboard entries for each event/car combination
-----EntityRef to Events
-----EntityRef to Cars
-----EntityRef to Challenges (optional)
Challenges - Allows members to "host" Challenges for specific Events
-----EntityRef to Events
-----EntityRef to Cars
Tournaments - Allows members to "host" Tournaments (a collection of Challenges)
-----EntityRef to Challenges
-----EntityRef to Users

In case your suggestion (in the form of a question) meant that I could reuse the same content types for ALL the various racing sites I have planned, perhaps this will answer it... The extensive use of EntityReference fields would pretty much eliminate that possibility. Take, for example, the Cars table... If someone is trying to enter a car for a Challenge, they should see *only* the cars for the game they are interested in, not ALL cars for ALL racing games. Also, not all games will use the same terminology (Series, Tiers, Events) nor have the same relationships between content types. That's why I foresee a new set of content types for each different racing site.

Thanks again for all the replies.

It's never too late to have a happy childhood. ;-)

In case your suggestion (in

Jaypan commented 27 February 2015 at 00:01

In case your suggestion (in the form of a question) meant that I could reuse the same content types for ALL the various racing sites I have planned, perhaps this will answer it... The extensive use of EntityReference fields would pretty much eliminate that possibility. Take, for example, the Cars table... If someone is trying to enter a car for a Challenge, they should see *only* the cars for the game they are interested in, not ALL cars for ALL racing games.

My question was a question, as I wasn't sure that I understood what you were talking about. But now that I do understand from your description, I do think you should re-use the content types for each instance. There are other ways to solve the issues you describe. Organic Groups is what I would suggest for this. You can then use entity reference views filters to ensure that only the cars for their game are shown.

Can you elaborate...

ExTexan commented 27 February 2015 at 00:08

Can you elaborate on how you would re-use content types?

I'm absolutely sure that no two games are going to have the exact same data for each of those different types I mentioned above. So the only way I can see to do what you're suggesting would be to have separate fields for each game for each content type. Then use different node displays (in addition to default and teaser) in order to show only the pertinent data for each site. That, and the use of Organic Groups, seems like a lot more trouble (and more confusing) than separate content types - and without really gaining anything in the way of reducing overhead. As far as I can see, the number of fields will, most likely, be the same, and even though it would reduce the number of actual content types, you have to add the overhead of OG.

It's never too late to have a happy childhood. ;-)

There is almost always more

Jaypan commented 27 February 2015 at 01:20

There is almost always more than one way to do things in Drupal. It sounds like you've already got a solution that works for you, so if it does, you may as well stick with it.

I wouldn't do it that way myself however. Basically content types are a template for a data type. Repeating that template due to the architecture of the site makes less sense to me than reusing the same template, and keeping the actual content separate through some grouping measure, whether that be permissions, filters, or groups. Organic Groups was basically made for the exact case you are describing. It's complicated to learn, but extremely powerful, and doesn't add a lot of overhead to the site overall. So I would (and do) use OG when I am faced with the situation that you have. But that doesn't make my solution right, or yours wrong, it's just different ways to do things. Choose the solution that works best for you - and it appears you already have.

You're right about always

ExTexan commented 27 February 2015 at 18:07

You're right about always having different ways to address any scenario in Durpal. One of it's many strong points.

Thanks for taking the time to reply in this thread. It's always good to hear about other approaches.

Cheers.

It's never too late to have a happy childhood. ;-)

I've generally found that the

thomasmurphy commented 20 September 2016 at 04:29

I've generally found that the larger your site gets, the more you wish you had less content types, in order to allow more VBOs, rules automation, etc.

How about this as a guide:
1 + 4*(log10(n) -1) where n is the number of nodes, which gives:

10 = 1
100 = 5
1,000 = 9
10,000 = 13
100,000 = 17

Another thing to consider, I

Jaypan commented 20 September 2016 at 04:59

Another thing to consider, I just finished my first D6 -> D7 migration, and each content type added more time/complexity to the migration process.

thank you all for this thread

green monkey commented 5 April 2019 at 16:42

not having much DB experience or knowledge, I found myself wondering this today. Drupal makes it easy to "have it your way" that a person could add too many layers on the hamburger. I caught myself, going that way today. When I realized that three of my new contents types could be combined one into content type ---- making long-term maintenance easier -- thanks again

my take-away summary: I could build a hundred+ content types if I have the resources, but why would I want to? ---- websites change all too often, be as ready as you can be

oh yeah, and who the heck likes to maintain websites --- when the juice (high) is building them

keep it simple ;)