我在尝试确定当前项目的数据库架构时遇到了一个小问题。我绝不是DBA。
应用程序根据用户输入解析文件，并在数据库中输入该数据。当前时刻可以解析的字段数在1到42之间。
数据库的当前设计是完全平坦的，有42列;有些人重复了一些列，例如address1，address2，address3等......
这说我应该规范化数据。但是，此时不需要数据完整性以及数据形成的方式我正在查看几个连接。这不是坏事，但数据仍然是1比1的关系，我仍然看到每行有很多空字段。
所以我担心的是，这不允许数据库或应用程序非常可扩展。如果他们想要添加更多要解析的字段（他们这样做），那么我需要创建另一个表并将另一个外键添加到链接表中。
第三个选项是我有一个表格，其中定义了字段，每个记录都有一个表格。所以我想的是创建一个存储值的表，然后链接到这两个表。问题是我可以根据输入的大小来描绘该表的大小。如果有人给我一个300,000记录而不是300,000 x 40 = 1200万的文件，所以我有一些保留意见。但是，我认为如果我达到这一点，我应该感到高兴，它正在被使用。此选项还允许更多自定义信息显示，即使您添加更多字段也需要更多工作，但很少返工。
所以问题归结为： 1.目前的设计是一个平面文件，它使得它难以延伸并且没有标准化。 2.规范化表格虽然目前没有实际好处，但需求发生变化。 3.将其标准化为名称值对，希望大小不会受到影响。
针对该表有大量插入，更新和选择。所以性能是一个担心，但我相信这句话现在是设计，后来进行性能测试？
我可能只是错过了一些实用的东西，所以即使这是一个快速的理智检查，任何评论都会受到赞赏。
感谢您的时间。
答案 0 :(得分：0)
进行健全检查总是好的。
你的陈述中的金块是：
他们想要添加更多要解析的字段
在这种情况下，我最初会使用您的名称 - 值对设计。维护将更容易，性能不应成为问题。
也许保留那些对实体来说是单数的属性...即实体上的“CreatedBy”或“CreatedOn”。对于那些重复，即“Address1”到“AddressX”或“Phone1”到“PhoneX”。
为了减轻连接的痛苦，请考虑为典型的SELECT模式或需求创建一个View。
答案 1 :(得分：0)
关于你问题的这一部分
所以我担心的是，事实并非如此 允许数据库或应用程序 非常可扩展。如果他们想要 添加更多要解析的字段（哪个 他们确实比我需要创造 另一个表，并添加另一个外国 链接表的关键。
如果只是添加其他字段，则无需添加其他表。这些只会进入主表，表示它是什么实体。
如果他们添加的新字段是针对新类型的重复组或者在功能上不依赖于实体，那么您只需要添加新表（因此您最终会重复相同的信息，更新异常的风险等等。）。