Fields API vs. fields in hook_schema

Question

Can someone please explain what is the advantage of using Fields API to create fields for an entity rather than just declaring them in hook_schema as values?

It's a bit of work to get all the fields defined, instances, options, allowed and default values, etc. and then you have to deal with getters and setters and finally uninstalling everything is not as simple as db_delete, esp if you have reference fields in use by other entities.

Answer 1

The most important advantage of using fields, rather than custom data in a custom table, is that your data has immediate integration with the rest of the system; including (but in no way limited to):

• Automatic integration with Views
• Potential to use EntityFieldQuerys
• Fields can be managed using the standard system UI, even if built in code
• Automatic integration with Features
• There are many contributed widgets that can enhance the UI of a field (e.g. the Term Reference Tree widget
• No need to load your custom data onto the node/entity in a load hook, the core field system does that for you
• No need to define CRUD operations for your data

I'm sure there are many, many more.

Basically, if you want fine-grained control over the operation/performance of your extra data then use a custom table. If you want the system to handle all of that for you, use a field. For what it's worth I pretty much always use a field to store any entity data these days.

Answer 2

As mentioned in the comment of Clive's answer, when having a custom entity built on top of Entity API's controllers invalidates most of Clive's points. You get CRUD, entity properties*, you can easily make your entity exportable, EFQ support, even views integration for free. And you have better performance because your data is in a single table and avoid to carry around the field definitions.

There still are a few advantages of using fields, though:

• Fields supports multiple values of every field type.
• You can store values for different languages and you get an UI for this with the Entity translation module.

• The Field UI, that allows to add additional fields to your entity. So for a re-usable entity, you might want to make it fieldable even if you don't add any fields yourself.

• Generated based on the schema, so you probably need to tune them a bit and add the proper type (boolean, date instead of int and so on).

Answer 3

Berdir and Clive are fully right.

In practice I found only one reason not to use fields: database performance. Every write/update of a field causes two INSERT statements. If you have 50 fields and you do a node_save() this will trigger 100 INSERTs.

Please note that this is not important if you have a few thousand nodes and write to them a few times an hour. But updating 10 million nodes in a batch is an other story. For such situations you should think about a custom entity built on top of Entity API's controllers as berdir mentioned or have a look at an alternative storage like MongoDB.