我在学习mysql，并且正在为工作而开发数据库。一切都很好，但我有一个问题。我正在组织财务报表（资产负债表，收益表，现金流量表等），大多数公司都有季度报表（未经审计）和年度报表（已审计）。现在，对于每项声明，我都有一个标记为年度或季度的专栏。更适合基于内容或视图创建表格吗？
其他人不可能同时对经审计和未经审计的报表进行报告，所以我在考虑是否值得为审计报表创建一个报表，以及未经审计的报表。我之所以想这是因为数据最终会变得相当大，我认为表格越小表现越快。
所以，当我在设计数据库，我应该在设计基于内容（即。这就是同组的一切，无论），还是应该我来分组基于人们将如何访问呢？
另一个问题便是，我应该通过countries..since下来我们坚定分组财务报表中所有的分析在90％同一国家
这是不可能在不知道整个问题的情况下明确回答的。
但是，通常需要单个表来表示系统中的每个逻辑实体。从它的声音来看，季度和年度报表代表了相同的逻辑实体，但因单个类别栏/栏位而异。国家问题也是如此 - 如果唯一的区别是国家（一个分类），那么他们可能应该全部存储在同一个表格中。
如果你是按类别划分资料单独的表，您的数据将被分散在多个表，并且将很难查询。例如，如果您想要统计系统中的所有语句，则必须查询所有国家/地区表并将结果添加到一起。
编辑： Joe Celko称这种反模式为“Attribute Splitting”。
首先我要指出的范围内，我不一位专业数据库设计师 但是，如果我是你，在这种情况下，我会创建一个表，因为实体基本相同。
如果你担心MySQL的啤酒上的数据集服务表现的，也许这将是更好地开始建立在Postgres的你的应用程序。如果你需要运行复杂的查询，你可以使用存储的函数/过程来提升mysql的性能，当然你也可以使用memcache或者任何nosql的东西来让SQL休息一下。
如果您确定用户将主要仅搜索这种或那种类型的记录，则可以构建三个表。其中一项为所有记录，其中一项为经审计和未经审计的记录。你可以让它们与InnoDB的触发器同步（ON UPDATE/DELETE/INSERT）。他们可以像意见一样工作，但我认为（未测试）他们会比观点更快。在这种情况下，您必须只管理第一个“大”表。如果你插入一个审计记录，触发器触发，并把记录到审计表中等等......
最良好的祝愿！
我同意Phil和Damien--一张桌子更好。你想要的是一张类型的真正的商业事物。如果您设计的表格与真实的东西相似，即使是抽象的或概念性的东西，那么您的数据设计也更有可能经受住时间的考验。一旦基于真实的数据描绘了一个模式，那么你可以回过头来应用规范化规则来形式化你的设计。
作为一项规则，设计一个您担心的性能问题是一个坏主意，但实际上并没有看到。你对大表慢的直觉可能实际上是错误的。大多数DBMS系统像大表一样，至少在某一点上。当表格很大时，查询优化器选择使用索引。当表格很小时，它们最终会得到全表扫描，这可能会降低并发访问速度。如果你的表变得如此之大以至于超出了你的数据库管理系统的能力，那么就该考虑将你不再使用的旧数据归档或者购买一个更具可扩展性的数据库管理系统。
感谢菲尔，我想你明白我的问题。也许我的问题更关系到mysql如何索引和搜索，但是会影响数据库效果性能的大小？例如，如果我搜索所有加拿大公司的平均季度收入（并且此数据库包含所有其他国家/地区的许多行以及年/季度数据），那么查询速度会很慢，因为它必须经过大量不相关的数据？ – Lostsoul 2011-05-05 21:11:21
在任何现代RDBMS中，设计合理的表可以处理数百万（如果不是数十亿）行，如果它甚至在中途体面的硬件上运行（并且被正确索引等）。除非你正在谈论一个非常庞大的数据集，否则我不会关心性能（甚至在我按类别分割数据之前，我会寻找其他选项）。 – 2011-05-05 22:00:26