Style Question - Database Table with Many Fields

I'm starting a new project where I have to parse a document and store it in a database. This document contains several sections of simple key-value pairs - about 10 sections and about 100 pairs in total. I could have one table per section, and they all map one-to-one to an aggregate. Or I could have one table with about 100 fields. I'm stuck because I don't want to make a single table that big, but I also don't want to make that many one-to-one mappings either. So, do I make the big table, or do I make a bunch of smaller tables? Effectively, there wouldn't really be a difference as far as I can tell. If there are, please inform me.

EDIT An example is desired so I will provide something that might help.

Document
  - Section Title 1
    - k1: val1
   开发者_开发技巧 - k2: val2
    ...
  - Section Title 2
    - k10: val10
    ...
  ...
  - Section Title n
    - kn-1: valn-1
    - kn: valn

And I have to use a relational database so don't bother suggesting otherwise.

If you have many, many instances of this big document to store (now and/or over time), and if each instance of this document will have values for those 100+ columns, and if you want the power and flexibility inherent in storing all that data actross rows and columns within an RDBMS, then I'd store it all as one big (albeit ugly) table.

If all the "items" in a given section are always filled, but invididual sections may or may not be filled, then there might be value in having one table per section... but it doesn't sound like this is the case.

Be wary of thise "ifs" above. If any of them are too shaky, then the big table idea may be more pain than it's worth, and alternate ideas (such as @9000's NoSQL idea) might be better.

If the data is just for read-only purpose and your xml doesn't mandate you to make DB scheme changes (alters) then I doesn't see any problem de-normalizing to a single table. The other alternative might be to look at EAV models

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

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

Yes, you have 100's of rows of name/value pairs per document. However, you can easily add names and values without having to revise the database.