Looking for core Drupal table DDLs
Those tables are generated dynamically by the field API, and as such don't have a pre-built DDL. This is essentially because fields can be added through the UI/programmatically after installation. Rather than keeping a monolithic registry of those fields and values, the architectural decision was made to split them out into dynamically-created tables with a conventional structure.

If you have corrupt field tables it's a bit...awkward. Drupal will already think the field exists because it'll still be listed in field_config and field_config_instance, so trying to add it again with the API/UI isn't going to work unless you also prune those records. 

Those records may also be referenced elsewhere (possibly in serialised PHP strings, no less), and there's no referential integrity of any sort here anyway, so you'd have to be able to work out what types of referenced record you could have, be able to identify them all, and nuke them. Not exactly easy.

The easiest approach will probably be a bit of a hack job; get the DDL of another field table, and twist it to match the table you've lost:

mysqldump -d -uroot -p &lt;dbname&gt; field_data_body


Give us

DROP TABLE IF EXISTS `field_data_body`;
CREATE TABLE `field_data_body` (
  `entity_type` varchar(128) NOT NULL DEFAULT '' COMMENT 'The entity type this data is attached to',
  `bundle` varchar(128) NOT NULL DEFAULT '' COMMENT 'The field instance bundle to which this row belongs, used when deleting a field instance',
  `deleted` tinyint(4) NOT NULL DEFAULT 0 COMMENT 'A boolean indicating whether this data item has been deleted',
  `entity_id` int(10) unsigned NOT NULL COMMENT 'The entity id this data is attached to',
  `revision_id` int(10) unsigned DEFAULT NULL COMMENT 'The entity revision id this data is attached to, or NULL if the entity type is not versioned',
  `language` varchar(32) NOT NULL DEFAULT '' COMMENT 'The language for this data item.',
  `delta` int(10) unsigned NOT NULL COMMENT 'The sequence number for this data item, used for multi-value fields',
  `body_value` longtext DEFAULT NULL,
  `body_summary` longtext DEFAULT NULL,
  `body_format` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`entity_type`,`entity_id`,`deleted`,`delta`,`language`),
  KEY `entity_type` (`entity_type`),
  KEY `bundle` (`bundle`),
  KEY `deleted` (`deleted`),
  KEY `entity_id` (`entity_id`),
  KEY `revision_id` (`revision_id`),
  KEY `language` (`language`),
  KEY `body_format` (`body_format`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Data storage for field 7 (body)';


Replace the table name and comment. Remove body_value, body_summary, and body_format columns, and the body_format index. These are specific to the body field type, the rest is boilerplate and common to all field types.

It seems likely your field type was a file reference, so you need to find the columns for that field type's schema. These are in file_field_schema(); mix these into your edited DDL:

`field_files_fid` INT(10) unsigned NOT NULL,
`field_files_display` TINYINT(3) unsigned NOT NULL DEFAULT 1,
`field_files_description` TEXT DEFAULT NULL


(add comments if you wish)

And an index for the file ID:

KEY `field_files_fid` (`field_files_fid`)


Repeat for the revision table (using field_revision_body as a starting point), and you should have your table structure back in place. At this point it would be a good idea to restore the data to these tables from a backup, as they reference entities in the file_managed table (and can have references elsewhere throughout the system).