That was a deliberate design choice for Drupal 7. The reasons were: - Loose coupling. Drupal has been becoming increasingly API-centric and storage engine agno

That was a deliberate design choice for Drupal 7. The reasons were: - Loose coupling. Drupal has been becoming increasingly API-centric and storage engine agnostic. Focusing on the physical storage schema for a DB engine misses the point of the architecture. - Performance(!) Supports schema changes on existing large datasets (migrations are only starting to appear in Drupal 8, and elsewhere bring their own complexities when you want zero downtime). Unsurprisingly there was some gnashing of teeth when this 'table per field' approach was introduced and as a result it was decided to build denormalized read layers on top (materialised views and bundles). However, it turned out that they showed no perf improvement over Drupal's object caching whilst adding complexity to the design and were therefore abandoned. (The fact that this performs as well as materialised views speaks very positively of Drupal's architecture and code quality.) - Multiple revisions of any data. - Multilingual capabilities. - Support of tree type data models. https://www.drupal.org/node/1035804#comment-6860070 https://www.drupal.org/node/1035804#comment-6860070 On the whole I would call this a thoughtful and reasonable design choice, and one that is supported by real-world implementation on millions of sites at all scales.