没有一个恒定统一的架构可以满足各种需求场景。 

在网站数据量少的情况下，那表太多肯定是表少一点更好。 如果数量达到一定量级， 数据库单表承受的数量是有限的。 在扩展性和负载均衡的考虑上，都不会让单张表承载过多的数据。举个栗子：电商、银行、电信网站查询近期订单和远期订单，通常不会在一个页面，后台也有对应的数据分表、分库处理。

从架构扩展性和性能考虑上来看，现在的数据表结构是合理很优的。

要分开来看，首先多表并不会很影响性能，因为Drupal已经为每个自动生成的表做好了索引，只是看起来很多。而自定义的话，可以实现在一个表中存储多个字段。而从使用模块的角度，或者开发者的角度，大多数情况，实际上是察觉不到多表的，因为是面向API在编程。

只有当我们直接面向数据库做查询的时候才会感觉到一些麻烦，但是性能上并不会有太大问题，我多次写过100行以上的SQL语句，也并不会慢多少，而这种查询大多是用于分析数据，而不是实现页面逻辑。

补充一下个人的一些体会。

刚开始我也很反感Drupal7的这种做法，甚至不愿意使用D7，但是时代毕竟要进步，不更新是没有出路的。

于是

我忍受着巨大的思想压力，慢慢使用D7。

时至今日，我仍然对D7的这种做法不是很满意，因为如果我要迁移数据库适配其他系统，太多的表依然不好管理。

那么问题来了，既然这么多缺陷，为什么还要这么做？

1. 如上@于志诚和@希望之翼的讲解，这个性能的损失是非常小的。

2. 灵活性高。
   这一点如果用过nosql就会有所体会，因为nosql基本都是key/value的存储，这种不要存储一张表，也就是不保存多个字段间的关系。
   这也是nosql的一个特性，这样高效灵活，业务逻辑抛到代码层。也就是说我只需要通过这个Id找到对应的值即可，至于跟其他字段的关系，数据存储层不需要考虑。因此，可移植性就好。
   ！！所以！！，D7使用这种方式存储每一个field，结果就是非常灵活，因此这个Field的存储可以很方便的移植到其他类型的数据库，比如redis、mongoDB等等。

所以，通过小的性能牺牲，换来更大的灵活和便利性，这也是D7的初衷。

当然，实在想不通，你只需要明白，一群人的智慧比我们一个人要牛逼！

继续补充下吧，上面的回答都够精彩。

稍微总结下，就是说：Drupal一个字段一个表的方式，以较小（比如1%）的性能牺牲，换来更大（比如10%）的灵活性与扩展性，这是非常值得做的交易。

另一方面，Drupal并没有限制你必须使用字段来存储你所有的数据；drupal7引入了entity概念；你可以通过hook_sechma定义自己的数据表结构，然后通过使用hook_entity_info将之封装之后，通过entity API非常方便的操作你的自定义数据表。

如果你连代码都懒的写，可以学习研究下eck模块。

-------------我是分割线---------------------

继续引申下，为什么你用Drupal,而不用php来做网站？

Drupal有其缺点，就是性能肯定不如纯php做的网站快；但是开发速度非常快。

PHP有其优势，但是开发速度肯定会慢很多。

自己考虑下，你最终会选择那种方式做网站呢？

很多选择都是权衡利弊之后的结果。

首先要说的是，用表数量，文件尺寸等标准衡量系统好坏是个很无厘头的事情；

其次，对于关系型数据库的这种列扩展方式，是古已有之，并不是Drupal的什么创举。

我的吐槽完了。