I need a sort of term database with around 3 fields that won't be used during normal site operations.. Only when I, the administrator, add content.

I'm wondering about how to minimise performance impact for regular users.. My intuition tells me that a field collection would be better so the nodes table is smaller.

I will be likely be using some code to add data from APIs and Rules to fetch the data by property.

Which should i use? I don't have much interest in creating a custom entity type unless it's really easy.. I want image and audio fields and I don't know if that complicates things.

  • Bonjour Niall! Not sure I fully get it, but how about making each of those 3 fields an entity reference field, pointing to some other content type (1 such type for each of those 3 fields). That way you don't "need" to use field collections, and have a variation of that custom entity type you want to avoid. And you can probably keep your rules relatively easy. Jun 23, 2017 at 11:53
  • Hi Pierre! See there's no overlapping data so having entity references would result in like 40,000+ nodes. Eg. ["Airplane" - definition, picture, translation, audio]. It's best to keep it all together. I already use field collections for other small parts of this site that I don't mind being slower and am comfortable with coding for them. It's really just a performance thing if using field collections will make impact regular nodes less. I don't know enough about databases to know for sure. Jun 23, 2017 at 12:18
  • Pierre, I am going to delete this question.. I think a second database would be better. I just found a goldmine of open-source data free to use commercially so my initial estimate of 10k will grow to more like 100k. Jun 23, 2017 at 12:30
  • @NiallMurphy - Quite interesting, general question. When using the external database will you import the content into Drupal then? This sounds like a good job for Feeds drupal.org/project/feeds
    – leymannx
    Jun 23, 2017 at 13:17
  • Yeah, I'm already using Feeds / Feeds Field Collection and a module to make other API calls. I have never looked at using a second database before but I think it would be perfect for what I want to do. Jun 23, 2017 at 13:33

1 Answer 1


Loading 1 node with like 10,000+ field collection items sounds like performance suicide if you don't limit the amount of items being loaded and displayed initially. And having to open a node with 10,000+ field collection items only to maybe add or edit one item will be really big pain then.

With nodes, much likely you'll never display all of them at once. You very likely will have them organised in Views. Limited display, pagers, filters, lots of caching possibilities. When you want to add a node, you'll have a fresh node form, loaded in milliseconds. Plus you will have a much larger number of contrib modules available dealing with sortability, searchability, orderability and a lot of other -abilities that come in handy when organising content. Also when it comes to content import.

Go for 10,000+ or even 1,000,000+ nodes. That's what Drupal is made for.

  • That all makes a lot of sense! At what number of nodes would you think a second database specifically for this would be worth it? All of these nodes will basically be used for data when creating regular nodes. Jun 23, 2017 at 13:48
  • @NiallMurphy - I'ld try to circumvent a second database as much as possible. You'll run into big problems sooner or later. Think of users, think of permissions, think of sessions, think of caching, think of updates. You'll have to deal with a lot of issues. One Drupal database is fine for millions of nodes.
    – leymannx
    Jun 23, 2017 at 14:01
  • @NiallMurphy - And one last recommendation as it's about performance and you still seem to be in the starting moves of an interesting great project. Start with Drupal 8 and with PHP 7. This probably will make your life much easier in the end. Much more high-performance at least.
    – leymannx
    Jun 23, 2017 at 14:03
  • 1
    @NiallMurphy - That sounds reasonable as you already are on track and you have the proven power of a very stable D7 and all it's reliable contrib modules available. Good luck!
    – leymannx
    Jun 23, 2017 at 14:10
  • 1
    The thing about Field Collection is this - every item constitutes 1 entity_load. So if you had a FC with 100 items, thats 100 entity_loads + all listening hooks or events on top of the page request itself. My advice, if you go with FC, is find a way to pre-render and cache the HTML before users visit the page. The performance otherwise will kill you without some sort of strategy.
    – Kevin
    Jun 23, 2017 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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