Field Collection vs Entity Reference

Question

How is field collection an advantage? You can do the same thing with a new content type pointing to the parent with an Entity Reference.

Maybe someone can break down some situations where each one would be better.

Say for Task -> Files, would field collection be better or a new content type with an Entity Reference?

Say for each file you needed more some other data about that file, sounds like a plan for a new type with an Entity Reference, but you can embed a field collection inside of a field collection.

I enjoy how Drupal has many ways of doing the same things, but I can't find much on how different or similar these two solutions are.

Maybe someone can help explain?

Answer 1

This is a question I make myself when facing new projects, Field Collection vs Entity Reference + custom entity or if the structure is simple, Field Collection vs custom field with several db columns / Multifield. Here's my opinion based in my experience.

Multifield is a great concept, it'd be a "lightweight" version of field collection, instead of creating an entity structure with relationships, it covers the simple use cases without creating the entity. It has a number of issues, though, such as not complete Features integration, not really multilingual etc (so if you plan to use this, contributions will be probably really welcome).

Field Collection is a great solution if you're doing a site that can be done just with a few tweaks here and there, it gives site builders a powerful tool to create complex structures without worrying much about the internals. It will basically create an entity that relates with the "host" entity by the ids, allowing to add fields to it and everything. The disadvantages would come in the knowledge of the internals of Field collection that you need to perform complex operations such as managing a Field Collection with an Entity Reference on it, or migrate data. As it is a generic tool, it'd be fairly complicated to go one step beyond.

Another option you've got there is using ECK with Entity Reference, but my experience with this has been a disaster so far, I find it way easier to create the entity type by code without the helper.

It's a matter of what you need and what's the best fit for your project, if you've got the time and the developers to create entity types that relate with your data model through Entity Reference, you'll have more control over what's happening with your data structures, but then you're the "responsible" for that too.

After testing a while with all the solutions describe above, in my team we always go for the entity types + ER, but I can see that for small projects, without data migration or a complicated i18n setup, Field Collection is just the fastest way to go.

Answer 2

It really depends on the data you input in the fields and the use you want to do with them.

If you want to use Field Collection, be sure you can to whatever is in your scope, from normal views, to translation, solr indexing etc..

If you want to reuse the information you add into a field collection, it will be better to use a content type or a custom entity. Example: A school course has got 5 topics. A topics contains 3 fields: Title, hours and level. If you are going to reuse topics in several school courses, go for an Content type/Custom Entity and use Entity reference.

Answer 3

They should be roughly equivalent in performance, but field collection uses the Entity API and does not require creation of a custom content type.