Question

我正在进行涉及时间序列分析的项目，我需要能够让用户上传包含他们自己的时间序列的文件（即带日期的数字），例如在.csv文件中。然后可以随时访问其文件中包含的数据，以便在我们的系统中使用。

我怎么能这样做？我想过的想法：

每次用户上传文件时创建一个表（并保存该表的名称）。如果我有很多用户上传大量数据，我可能会得到大量的表格。
创建一个基本上有三列或四列的大胖怪表：值的日期;价值;数据集名称（和/或数据集的所有者）。所有内容都上传到该表中，当Bob需要其天气数据时，我只选择（日期，值）所有者= Bob和datasetname = weatherdata。
在解决方案之间：每个用户一个表，所有Bob的数据集都在Bob的表中。
完全不同：只需将.csv文件保存在某个地方，并在需要时阅读。

我一直在阅读这是一个不好的做法，有不同数量的表（我相信它）。但是我的情况与我在这个网站上看到的其他问题略有不同（大多数人似乎想为每个用户创建一个表，当他们应该为每个用户创建一行时）。

其他一些信息：

时间序列数据可能包含数十万个观测值，可能是数百万个
先验，之后不应修改已保存的数据。但是我想让用户在他们的时间序列中附加新数据会很有用。
先验，我不需要做复杂的SQL select语句。我只想阅读鲍勃的天气数据，我可能会按时间顺序使用它 - 虽然你永远不知道明天会带来什么。
使用PostgreSQL 9.1，如果这有任何重要性。

修改阅读一些答案我意识到我可能没有完成我的工作，我应该说我显然已经在SQL环境中发展;我已经有了一个User表;当我写“桌子”时，我的意思是“关系”;我的所有4个想法都涉及外键;除非其他方面更好，否则RDBMS规范化就是范式。（这一切并不意味着我反对非-sql解决方案）。

Answer 1

我将不得不选择“大胖子怪物桌”。这就是关系数据库的工作方式，尽管你应该对其进行规范化（为用户创建一个表，为数据集创建另一个表，为数据点创建另一个表）。拥有相同模式的多个表从各个角度来看都是一个坏主意 - 设计，管理，安全性，甚至是查询;你确定你永远不想要合并来自两个数据集的信息吗？

如果您确定每个数据集都是完全隔离的，那么您可能还会考虑根本不使用SQL。 HDF（分层数据格式）字面为此目的而构建，有效存储和检索“科学数据集”，这些数据通常是时间序列数据。 HDF中的“表”字面上称为数据集，它们可以共享定义，它们可以是多维的（例如，当天的一个维度，时间的一个维度），并且它们比SQL表便宜得多。

我通常不会试图引导人们远离SQL，但是异常情况有时需要不寻常的解决方案。如果您要在SQL表（或更多）中以数十亿行结束并且您实际上没有要存储的其他数据，那么SQL可能不是适合您的解决方案。

Answer 2

可能设计的示例T-SQL *：

CREATE TABLE dbo.Datasets (
    ID          int NOT NULL IDENTITY(1,1),
    OwnerUserID int NOT NULL,
    Loaded      datetime NOT NULL,

   CONSTRAINT FK_Datasets_Users
       FOREIGN KEY ( OwnerUserID )
       REFERENCES dbo.Users ( ID )
);

CREATE TABLE dbo.DatasetValues (
    DatasetID   int NOT NULL,
    Date        datetime NOT NULL,
    Value       int NOT NULL,

    CONSTRAINT FK_DatasetValues_Datasets
        FOREIGN KEY ( DatasetID )
        REFERENCES dbo.Datasets ( ID )
);

设计模拟了您的问题中隐含的两个“实体” - 正在加载的时间序列数据和设置时间序列数据。

*对于SQL Server;我知道你说PostgreSQL 9.1，但我很确定你可以轻松翻译。

Answer 3

你的想法都是完成任务的好方法（希望我能正确阅读）。

关系数据库怎么样？例如，具有用户名，上载时间和唯一数据ID的表，然后将dataid链接到包含dataid外键和原始文件数据的另一个表。这将使用户表保持最小（并且您可以将其与另一个表合并，例如包含用户详细信息）。有一个单独的表供用户使用，另一个用于密码，另一个用于电子邮件，然后另外5个用于数据可能是不好的做法，但我个人认为从用户数据中分离文件没有任何问题。

您使用什么语言处理数据？这也可能是一个决定性因素。

希望这会有所帮助：）

汤姆

Answer 4

好的我认为选项2是最好的，创建额外的表只是一个维护的噩梦，让你容易受到如此多的错误等。选项4有点吸引人但我仍然认为数据库应该能够应对这种任务。

我想我会像这样构建我的表：

用户表 - 用户ID，名称等

行 - 上传数据中的每一行（rowid等）

RowInDataSet - 行ID，DataSetID

DataSet - DataSetID，上传日期，UploadBy等

这使您可以稍微分解数据并使其易于维护。如果正确索引这些表，则存储大量数据不应该是这样的问题。

SQL：你如何保存用户自己的数据？

4 个答案: