Дизайн базы данных для временных рядов в SQL

Question

У меня есть данные геолокации с метками времени и некоторая другая информация о пользователях, и я ищу совет по проектированию базы данных. Я предполагаю, что наивный дизайн будет:

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),
);

Здесь xloc, yloc - это числа с плавающей точкой, указывающие местоположение. Очевидная проблема с этой таблицей заключается в том, что поля gender, age и name будут избыточно повторяться много раз для каждой временной отметки. Прочитав исчерпывающий принятый ответ в Хранение данных временных рядов, реляционных или не относящихся к? Я решил, что лучшим решением было бы иметь данные геолокации в отдельной таблице, т.е. иметь две таблицы:

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 в качестве PK, чтобы попытаться соответствовать Шестая нормальная форма (6NF) , как указано в ответе выше. ссылка - это, по-видимому, обеспечивает более высокую производительность. Строго говоря, для 6NF требуется только один другой атрибут для каждого PK , но в моем случае у меня есть два (xloc и yloc). Последние версии PostgreSQL позволяют использовать типы массивов , поэтому другой вариант будет:

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, в этом порядке, но пока это не проблема. В настоящее время таблица технически имеет только один атрибут на ПК, но меня больше интересует его производительность. Я новичок в Postgres и БД в целом. Будет ли использование типов массивов лучше с точки зрения производительности?

Данные и сценарий использования: Временные ряды местоположений для каждого пользователя могут быть длиной в десятки миллионов измерений и с различными интервалами. read ops превысит число write ops - на самом деле сейчас мои данные статичны, и полученная база данных будет использоваться небольшой командой для статистического анализа, по крайней мере, на данный момент. Мои запросы будут, например, измерения для пользователей мужского пола или воскресные измерения для пользователей младше 30 с .

Какие альтернативные проекты вы бы порекомендовали?

Answer 1

Временные ряды и временные данные сами по себе не используют 6NF.(Поместите эту ссылку.) Необходим CK и связанные данные, в которые вы хотите записать атомарные изменения.6NF просто часто требуется, но сама по себе не является целью.Данные не-CK могут быть несколькими столбцами - вы хотите записывать изменения в местоположении, а не в координате.(Точно так же, когда вы хотите узнать, изменилось ли целое число, никто не потревожился тем, что у вас нет таблицы для каждого CK и цифры.) Вы можете думать об этом как о преобразовании таблицы 6NF с CK и одним кортежем или записью.столбец со значением.

Так что здесь хорошо подходит дизайн с CK & X & Y - до тех пор, пока вам не нужно знать, когда изменилось конкретное значение координаты.

"I"Я новичок в Postgres и БД в целом. "Затем забудьте о «производительности», пока не научитесь достаточно понимать, что это значит.Делайте простые дизайны.Далее узнайте об ограничениях и индексах.

Временные данные (включая 6NF), каждый должен прочитать Дата, Дарвен и Лоренцос.Избегайте Snodgrass.

PS PK не имеют отношения к теории реляционных моделей, CKs имеют значение, а PK - это просто некоторый CK, который вы назвали PK.PS Остерегайтесь, что SQL PK более или менее суперключ, а не CK;он может содержать меньший UNIQUE / суперключ.

PS 6NF означает, что не удовлетворяет нетривиальным JD.Это подразумевает «Первичный ключ и не более одного другого атрибута», но последний не является определением 6NF.Также обратите внимание, что это условие само по себе не означает точно один CK;их может быть и больше.

PS Википедия не является источником звука для информации о реляционных моделях.Например, Нет ни одного "1NF" , и они ортогональны нормализации к NF, ведущим к 6NF.Например, ПК не имеют значения.Например, нормализация к более высоким NF не осуществляется путем перемещения через более низкие NF.(Более того, это может помешать хорошим проектам NF назначения.) Например, DKNF не принадлежит на этой странице среди NF, ведущих к 6NF.Например, его определение 6NF неверно.