SQL Server/表设计，用于数据快照的表，其中可能有数百列

我们有一个业务流程，需要在某个时间点对客户数据的一部分进行“快照”，并能够在以后将其返回。尽管数据集有一些奇怪之处，但这让问题变得有趣：

• 数据是从几个数据库中提取的，其中一些数据库不是我们的
• 可能被提取的字段列表大约在150到200之间
• 通常提取的字段列表在10到20之间
• 每个客户端都可以提取一组用于存储的自定义字段，这组字段是预先确定的

例如（我把这些大大简化了）：

• 客户A决定在周五拍摄客户地址快照（每个客户地址一条记录）
• 客户B决定每隔周二拍摄汇总发票信息的快照（每种发票类型1条记录）
• 客户C每月汇总每个部门的工作时间（每个部门1条记录）

当这些周期中的每一个周期发生时，都会有一个进程退出并为每个客户机获取适当的信息。。。对他们做点什么

听起来像是一个历史报告系统，对吗？有点像。根据客户的需要，数据随后被解析并以各种格式（xml、cvs、excel、文本文件等）返回

我得重写一下

因为我们并不拥有所有的数据库，所以我不能只保留对周围数据的引用。无论如何，其中一些数据会定期被覆盖。我实际上需要找到合适的数据并把它放在一边

我希望有人能想出一个聪明的方法来设计这种野兽的桌子。想到的方法都有各自的缺点：

数据集表（数据集id、捕获日期等）； 数据表（数据集id，行号，“数据是一团垃圾”）

数据集表（数据集id、捕获日期等）； 数据表（数据集id、行号、可能字段1、可能字段2、可能字段3、…、可能字段x（其中x>150）

数据集表（数据集id、捕获日期等）；字段表（所有可能的字段类型各一行）；选定字段表（客户机选择的每个字段各一行）；每个可能的原始数据类型（varchar、decimal、integer）各一个表（键入选定字段，数据集id、行、位置，数据为单个字段值）

第一个是最容易实现的，但是“垃圾块”必须被设计成可解析的，以将其分解为可报告的字段。数据库也不是很友好，不可报告，等等。感觉不太对

第二个是一个恐怖的栏目秀

第三个听起来不错，但有点不对劲。它是3NF（是的，我老了），所以感觉是对的。然而，在表上报告“应该是列的行”问题——在程序之外尝试选择是毫无用处的

你的想法是什么？

关于“可能有数百列的地方”
限制是每个表有1000列

---

有趣的问题，但超出StackOverflow的范围。可能是程序员的问题。stackexchange.com（请检查，我不确定）？