Как перепроектировать базу данных с большим количеством значений в строке

Question

Я строю базу данных (mysql) для сбора данных от различных клиентов. Набор данных, который я получу, будет временной меткой (Datetime) и 600 значениями (числами с плавающей запятой или логическими переменными). Каждый клиент генерирует набор данных каждые 5 минут. Целью сбора всех этих данных является их последующий анализ, отфильтрованный по дате и времени клиента.

Моей первой идеей было создать таблицу с большим количеством столбцов, примерно так:

¦ id ¦ отметка времени ¦ client_id ¦ val_1 ¦ val_2 ¦ ... ¦ val_600 ¦

Где: 'id' - поле первичного ключа с автоинкрементным целым числом, 'timestamp'a поле даты и времени, 'client_id' - это целочисленное поле, которое ссылается на клиента в другой таблице, 'val_n' - это текстовое поле, оно остается гибким, потому что не каждый клиент предоставляет один и тот же набор данных (у некоторых есть только числа с плавающей запятой, у некоторых может быть 200 или 300, а у некоторых - только логические значения или любое их число). Структура набора данных определен в другой таблице, на которую также можно ссылаться через 'client_id').

---

Моя база данных с ее таблицами похожа на описанные обычные формы и работает как все. Но так как я много читал о дизайне базы данных, я увидел много горячих (в основном здесь) людей, которые просили составить таблицу с более чем 20 столбцами. Похоже, что при этом может возникнуть много проблем.

Но я не знаю, как делать по-другому, единственное, о чем я могу думать, это:

¦ id ¦ временная метка ¦ client_id ¦ float_data ¦ boolean_data ¦

Где: 'float_data' и 'boolean_data' оба будут текстовыми полями, а внутри этих двух полей будет сериализованный словарь, например: {"1": 23.4, "2": 87.2 ...}.

В этом случае я бы явно не использовал количество столбцов. Недостатком этого является то, что если я хочу узнать значение 46 от клиента и мне нужен набор этих данных в течение 10 дней (было бы 2880 строк), мне пришлось десериализовать каждый из этих диктовок и выбрать правильное значение в соответствии с его значением. Ключ. Это кажется мне неосуществимым.

---

Дело в том, что я довольно новичок в базах данных, и я боюсь, что этот дизайн таблиц однажды станет проблемой. Кто-нибудь знает лучшее решение, чем два моих подхода, или я сильно волнуюсь и должен запустить его так?

Answer 1

План A: если 600 значений «одинаковы»; то есть это массив похожих показаний. И вы будете допрашивать некоторых из них. Затем создайте второй стол с id (из основного стола) плюс 1..600.

План Б: Вы не будете использовать какие-либо запросы MySQL к значениям. Скопируйте их в строку JSON (или другую сериализацию) и сделайте это столбцом. Если возможно, сожмите его в клиенте - это сэкономит около 2/3 пространства.

Answer 2

Недостатком этого является то, что если я хочу узнать значение 46 от клиента и мне нужен набор этих данных в течение 10 дней (было бы 2880 строк), мне пришлось десериализовать каждый из этих диктов и выбрать правильное значение в соответствии с его ключом. Это кажется мне неосуществимым.

Что если mysql может сделать эту работу за вас? Последние версии mysql поддерживают типы данных json https://dev.mysql.com/doc/refman/8.0/en/json.html,, которые, по моему опыту, отлично подходят для случаев, когда вам нужна гибкость при поступлении данных.

https://dev.mysql.com/doc/refman/8.0/en/json.html

Это главным образом заботится о недостатке, потому что вы можете запрашивать данные json, как если бы они были столбцами - не так быстро, как действительно нормализованные таблицы, которые очень эффективны, но все же, вероятно, быстрее, чем копаться в n столбцы для поиска подходящих данных (что обычно очень медленно, потому что формат несовместим с методами, которые базы данных используют для эффективной обработки данных, и потому, что в каждой строке много данных, которые не могут быть по существу проиндексированы).

Вы все еще хотите нормализовать все возможные данные. Такие вещи, как идентификатор клиента, дата получения и т. Д., Вероятно, имеют смысл быть нормализованными. Остальные могут быть отправлены как объект json и сохранены как есть в базе данных, относительно эффективно запрашиваются во время выполнения, как того требуют сценарии использования.