我在决定如何将这些数据存储在我的数据库中时遇到了问题。关于最好的方法有什么建议吗？我对数据库知之甚少，我可能会补充。
我的数据格式如下，但不是 4，列数约为 240，因此每个日期都有 240 个与之关联的唯一值：
Date/Time 200,00 202,50 205,00
2010.11.12 13:34:00 45,8214 43,8512 41,5369
2010.11.12 13:35:00 461,9364 454,2612 435,5222
此外，行与 DataSites 相关联。
我的第一个想法是有一个像这样的表：DataID (pk)、DataSiteID、ParameterID、Date、Value，在 DataSite、Parameter 和 Date 上有一个索引。ParameterID 指的是另一个存储输入列标题的表 (200,00 202,50 205,00 ...)。
我的第二个想法是拥有一个包含所有 240 多列的表格。我想出了其他一些方法，但它们也很不令人满意。
我的第一个解决方案的问题（不是那么大的问题，但我不喜欢它）是日期和 DataSiteID 将重复输入行中的所有 240 个值，因此它使用了很多的额外空间。
每年会有大约40GB的数据进来（上面的文本格式），数据会通过DataSite、Parameter和Date进行搜索。传入的数据量很可能会在一年左右的时间内翻两番。
有什么好主意吗？谢谢，詹姆斯
编辑：这是时间序列数据，列是不同波长的测量值。数据需要在相对较窄的波长范围内进行分析。在未来的某个时候，也可能会添加额外的波长。
编辑：感谢大家的回答，我真的很感激:) 我想我可能会找时间用 500GB 左右的测试数据运行一些实验。我会带着任何结论回帖;)
Eri*_*elp 10
您可以采用任何一种方式创建案例，但如果数据将用于分析并且您经常希望同时查看该数据中的多个列，请使用宽表。确保您知道您的数据库列数量和行大小限制。确保您获得正确的数据类型。如果许多列为空，SQL Server 允许您为此优化表。您还可以考虑使用 NOSQL（不仅是 SQL）解决方案来分析此类数据。
如果用于分析的数据将减少，您可能希望按照问题中的说明对其进行标准化。
小智 6
我和你的情况非常相似，257 个字段，每年 30-50GB。我最终只是保持简单，SQL Server 中的一个长长的大男孩表。我的数据被查询了一些，但主要是日期，并且运行良好。
我本可以将数据分解成逻辑上更小的夹头（50 个左右的组），但在这种情况下，它确实没有太大的优势，所以我省去了自己的麻烦。
如果我现在觉得很花哨，我可能会考虑一个理论上更适合的 NoSQL 选项，但是对于任务关键数据，尝试新事物并不总是对神经有益。
所以，为了迟到地回答我自己的问题（该项目最终没有进行），当我设法获得一些空闲时间时，我用 500GB 的数据填充了一个测试表，表的排列如下：
我的第一个想法是有一个像这样的表：DataID (pk)、DataSiteID、ParameterID、Date、Value，在 DataSite、Parameter 和 Date 上有一个索引。ParameterID 指的是另一个存储输入列标题的表 (200,00 202,50 205,00 ...)。
数据库设置是标准 PostgreSQL 安装在具有 3GB 内存的旧双核机器上。我运行了大约十几个不同的查询，只是通过 DataSite Date 和 ParameterID 选择数据，平均 1 小时时间段、1 天时间段的数据，并插入新的数据块。从内存中，所有查询的执行时间不到一秒钟。它肯定比我预期的要快得多，而且非常有用。我没有想到的一件事是，以这种方式索引的表的索引文件也几乎是 500gb，因此使用 240 列宽的表肯定会节省大量磁盘空间。