Database 样式问题-具有多个字段的数据库表

我正在开始一个新项目，我必须解析一个文档并将其存储在数据库中。本文档包含简单键值对的几个部分-大约10部分，总共大约100对。我可以每个部分有一个表，它们都一一映射到一个聚合。或者我可以有一个大约有100个字段的表。我被卡住了，因为我不想创建一个那么大的表，但我也不想创建那么多的一对一映射。那么，我是做大桌子，还是做一堆小桌子？事实上，就我所知，这并没有什么区别。如果有，请通知我

编辑 需要一个例子，所以我将提供一些可能有帮助的东西

Document
  - Section Title 1
    - k1: val1
    - k2: val2
    ...
  - Section Title 2
    - k10: val10
    ...
  ...
  - Section Title n
    - kn-1: valn-1
    - kn: valn

我必须使用一个关系数据库，所以不用麻烦提出其他建议

Table document(
     PK - a surrogate key
     name - the "natural" key
)

Table content(
     PK - the PK of the parent document
     section title
     name
     value
)

---

是的，每个文档有100行名称/值对。但是，您可以轻松地添加名称和值，而无需修改数据库。

如果数据仅用于只读目的，并且您的xml不要求您进行DB方案更改（更改），那么我认为将其反规范化为单个表没有任何问题。另一种选择是，如果要存储这个大文档的很多实例（现在和/或以后），如果这个文档的每个实例都有100多个列的值，并且如果您希望在RDBMS中存储跨行和跨列的所有数据所固有的功能和灵活性，那么可以查看，然后我会把它们都放在一张大桌子上（尽管很难看）

如果给定部分中的所有“项目”都已填写，但内部部分可能已填写，也可能未填写，则每个部分有一个表可能有价值。。。但听起来情况并非如此

---

注意上面的这些“如果”。如果其中任何一个太不可靠，那么大桌子的想法可能会带来更多的痛苦，而其他想法（如@9000的NoSQL想法）可能会更好。

你能举个例子吗？这两种情况听起来都不理想，这可能是因为我脑子里没有你想做的事情。使用这种方法，NoSQL数据库可能有优势。我希望我可以使用NoSQL。它更合身。但是客户不能支持，所以我被卡住了。这张巨大的表格是所有表格的共同点，整个表格都必须填写。我还有其他关于部门特定部分的表格。