The Field API generates a table storing data for each field. The structure of each record in the table includes two 128 character indexed fields -- one for the entity and one for the bundle to which the field is attached.
In the instance of making a boolean field, 300 bytes of data (256 of which are indexed) are used to store each boolean field containing a single bit of information.
This overhead is duplicated in the revisions table for the field. This results in wasted space and extra computer processing to find or save all that indexed information.
This storage overhead makes it problematic to use the Field API in applications that will store and access large quantities of data.
A New Field API could be much more efficient by saving simple two-byte integers that map to entity type and bundle information and using a mapping function to convert entity and bundle names to their appropriate integers. The New Field API could coexist with the old-school Field API, but provide leaner performance for new development.
Additionally, the names of entities and bundles would no longer be limited to 128 characters. They could be of arbitrary length.
Recent comments
Hi @Gnome and welcome to Backdrop When I create custom layout templates I put them in /layouts/custom/my_layout Note: you can split modules and layouts between contrib and custom...
My layout template (layout--blog.tpl.php) doesn't work
This post explains how to do this in Drupal 7. In Backdrop, File Entity is already part of core. You will need to download and install module Views Field View. https://drupal.stackexchange...
I Need to Display an Image in a View that was Uploaded to a Webform
After alot of trials, i have done the obvious and translated the whole block for different languages with each property condition as follows: ->propertyCondition('langcode', 'en...
How to get the current page language?