SQL中timeseries的数据库设计

我有时间戳地理位置数据和一些关于用户的其他信息，我正在寻找设计数据库的建议。我想一个天真的设计应该是：

CREATE TABLE user(
    user_id INT NOT NULL,
    name VARCHAR(128) NOT NULL,
    gender VARCHAR(128) NOT NULL,
    age INT NOT NULL,
    time TIMESTAMPTZ NOT NULL,
    xloc FLOAT(4) NOT NULL,
    yloc FLOAT(4) NOT NULL,
    PRIMARY KEY(user_id),
);

CREATE TABLE geodata(
    user_id INT NOT NULL,
    time TIMESTAMPTZ NOT NULL,
    loc FLOAT(4) ARRAY[2] NOT NULL,
    PRIMARY KEY (user_id, time),
);

这里的

xloc、yloc

是表示位置的浮点数。此表的一个明显问题是，对于每个时间戳，

性别

、

年龄

和

姓名

字段将重复多次。在阅读了中非常全面的公认答案后，我决定更好的解决方案是将地理位置数据放在单独的表中，即有两个表：

CREATE TABLE geodata(
    user_id INT NOT NULL,
    time TIMESTAMPTZ NOT NULL,
    xloc FLOAT(4) NOT NULL,
    yloc FLOAT(4) NOT NULL,
    PRIMARY KEY (user_id, time),
);

CREATE TABLE user(
    user_id INT NOT NULL,
    name VARCHAR(128) NOT NULL,
    gender VARCHAR(128) NOT NULL,
    age INT NOT NULL,
    PRIMARY KEY (user_id),
);

请注意，在

geodata

表中，我使用

user_id

和

time

作为主键，试图符合上面链接中答案所建议的第六范式（6NF）——这可能会实现更高的性能。严格来说， ，但在我的例子中，我有两个（

xloc

和

yloc

）。最近的PostgreSQL版本允许用户使用，因此另一个选项是：

CREATE TABLE user(
    user_id INT NOT NULL,
    name VARCHAR(128) NOT NULL,
    gender VARCHAR(128) NOT NULL,
    age INT NOT NULL,
    time TIMESTAMPTZ NOT NULL,
    xloc FLOAT(4) NOT NULL,
    yloc FLOAT(4) NOT NULL,
    PRIMARY KEY(user_id),
);

CREATE TABLE geodata(
    user_id INT NOT NULL,
    time TIMESTAMPTZ NOT NULL,
    loc FLOAT(4) ARRAY[2] NOT NULL,
    PRIMARY KEY (user_id, time),
);

在这种情况下，客户机应该知道数组以该顺序表示

x

和

y

位置，但目前这不是问题。从技术上讲，这个表现在每个PK只有一个属性，但我对它的性能更感兴趣。我是博士后和DBs的新手。就性能而言，使用数组类型会更好吗

数据和用例：每个用户的位置时间序列可以是数千万次测量，并且间隔不同。读操作的数量将超过写操作——事实上，现在我的数据是静态的，生成的数据库将被一个小团队用于统计分析，至少目前是这样。 我的查询将是男性用户的测量值，或30岁以下用户的周日测量值

---

您会推荐什么替代设计？

时间序列和时间数据本身不使用6NF。（调整链接的速度。）所需的是一个CK&相关数据，您希望记录原子更改。6NF只是经常需要，但它本身并不是目标。非CK数据可以是多列——您希望记录对位置的更改，而不是对坐标的更改。（类似地，当你想知道一个整数是否改变了，没有人会因为你没有一个表来代表每一个CK和digits而感到不安）你可以把它看作是一个6NF表与CK和一个元组或记录值列的转换

所以在这里，使用CK&X&Y的设计是很好的——只要您不需要知道某个特定的坐标值何时改变

“一般来说，我对博士后和DBs都是新手。”然后忘掉“表现”，直到你充分了解它的含义。做简单的设计。接下来了解约束和索引

关于时间数据（包括6NF），每个人都应该阅读Date、Darwen和Lorentzos。避免鼻涕草

PS-PKs与关系模型理论无关，CKs-matter&a-PK只是一些你称之为PK的CK。PS注意，SQL PK或多或少是一个超级键，而不是CK；它可以包含较小的唯一/超级键

PS 6NF意味着不满足非平凡JDs。它意味着“主键，最多一个其他属性”，但后者不是6NF的定义。还要注意的是，这种情况本身并不意味着只有一个CK；可能还有更多

---

PS Wikipedia不是关系模型信息的可靠来源。Eg&它们与NFs的标准化正交，从而产生6NF。没关系。例如，向更高NFs的标准化不是通过移动较低的NFs来完成的。（此外，它可以排除良好的目标NF设计。）例如，DKNF不属于导致6NF的NFs页面。例如，它对6NF的定义是错误的。

@a_horse_和_no_名字当然是相关的，因为“6NF”在这之外没有任何意义。非常感谢您的输入。我同意，首先让它发挥作用，然后关注性能是正确的方法。但是在我的例子中，性能对于进行查询和分析的团队来说是极其重要的。现在，我们有数十万个测量文件放在一个文件夹中，我们只是直接批量加载文件进行分析等。如果数据库速度大大减慢，团队将不会使用它。因此，如果我理解正确，我应该使用CK&（X，Y）而不是CK&X&Y（即X，Y的数组类型而不是单独的列），对吗？每个位置测量都是一个原子

（x，y）

，而不是

x

和

y

是独立的东西。我肯定永远不会只查询

x

或

y

列。我说过使用CK列和x&y列。我认为“CK&x&y很好——只要你不需要知道某个特定坐标值何时更改”，这一点很清楚。你是我解释过的一个数组没有理由&。请参阅我的下一条评论。PS您的分解为2个表显然是独立于您的应用程序所需要的。是时候读一本关于信息建模、关系模型和数据库设计的教科书了。然后是针对您的DBMS进行优化。我当前的一般评论是“更好”/“最好”等：除非您定义，否则在工程中没有“更好”/“最好”这样的东西。同样不幸的是，所有合理的实用定义都需要大量的经验，其中包含大量的因素，这些因素与对细节的敏感度混乱相互作用。做简单的设计。当你通过测量证明一个设计和你能想到的所有备选方案都有问题（无论当时是什么意思），然后问一个非常具体的问题。还应定义“更好”/“最佳”。“CK&X&Y很好——只要你不需要知道某个特定的坐标值是什么时候改变的”——这是我不理解的部分，不是应该相反吗？如果我对

x

和

y

有单独的列，我不是在告诉数据库这些是独立的属性吗？