问还有什么更好的？具有相同实体的多个表与拥有更多记录的关系表

EN

首先，除非您期望数以百万计的记录不太关心性能，而是更关心数据的结构以及访问它的容易程度。逐字逐句地写下您计划在应用程序中提取的数据列表，例如“今天查找所有问题”、“查找所有6个月前未解决的问题”，然后尝试在您预期的结构上构建真正的SQL查询。如果他们要努力改变结构。

回答你的问题:视情况而定。目前的结构有以下好处：

• 很容易质疑某些类型的问题
• 构建PHP应用程序很容易--只需创建一个模板表单(或模型)，然后对其他表进行轻微更改就可以复制它。
• 在出现性能问题的情况下，简单地将每个表放在不同的db服务器上，可能更容易创建集群。

以下是不利因素：

• 太僵硬了。添加开始时忘记添加的新字段将是痛苦的，因为您必须更改3个(或更多)表，然后在应用程序中更改相同数量的表格。
• 添加新类型的问题将是痛苦的，需要创建新的表。
• 创建SQL-s来获取数据，如“所有未解决的问题(无论类型如何)”，都需要复杂的UNION-s。此外，此UNIONS将要求创建具有问题类型的虚拟字段，否则您将无法判断某些id来自哪个表。

传统的db方法建议对公共字段使用一个表，并为不同的字段创建派生表。所以：

• issues表应该具有所有公共字段，并由PK issue_id标识。
• municipal_issues使用issues.issue_id的外键，并且只有特定的字段
• harassment_issues使用issues.issue_id的外键，并且只有特定的字段
• 此外，issues表有一个issue_type字段，该字段采用值“骚扰”、“市政”等，并帮助查找存储附加数据的表。

这种模式称为"类表继承“，您可以查看SQL反模式演示文稿以获得更多信息和其他方法。这解决了灵活性问题，并且仍然允许只使用一个快速的简单连接重新创建每个原始表。

另外，您可以查看像螳螂这样的bug跟踪器的db模式，因为这看起来是相同的域。