дизайн базы данных, вопрос о внедрении

Question

Вопрос относительно моего дизайна базы данных sql для проекта, над которым я работаю.

Я буду получать данные каждые несколько секунд, и мне нужно будет сохранить эти данные в базе данных. Я использую MySQL для моей СУБД. Данные должны храниться в базе данных с идентификатором пользователя, прикрепленным к каждому фрагменту данных. Я буду обрабатывать только одного пользователя для каждого приложения. Таким образом, каждый экземпляр приложения будет обрабатывать только данные одного пользователя. В удаленной базе данных будут храниться данные всех пользователей. Вот почему мне нужны идентификаторы пользователей, чтобы знать, чьи данные это чьи.

Моя идея состояла в том, чтобы подождать, пока я получу примерно 50 пакетов данных, и создать строку с разделителями из всех 50 пакетов данных. (Может быть разделены запятыми) Затем вставьте эту строку в базу данных вместе с идентификатором пользователя. И хранить данные так. Мой вопрос, это хороший способ сделать это? Есть ли способ лучше? Это плохая практика? ПОДСКАЗКИ ПОЖАЛУЙСТА! =)

Я получу много этих данных. Один пакет данных, как каждую секунду, иногда быстрее. Просто дай мне знать, что ты думаешь.

СУБД будет работать на удаленной машине. Приложение будет работать на телефоне Android.

Заранее спасибо!

Answer 1

Я бы не советовал объединять кучу значений для отправки строки с разделителями в базу данных. Это просто создает дополнительную работу с базой данных для разбора строки.

Любая разумная среда для взаимодействия с базой данных позволит вам создавать и отправлять пакеты базы данных SQL с различными значениями переменных связывания в базу данных. Это поддерживает приятный, дружественный синтаксис хранимой процедуры или оператора INSERT, обеспечивает правильную нормализацию базы данных и позволяет достичь производительности, сводя к минимуму количество циклов.

Answer 2

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

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

Answer 3

Если база данных работает на хорошем сервере, и все, что вы делаете с данными, это простая вставка в достаточно простую таблицу, 1 вставка в секунду не должна напрягать вообще. Я ожидал бы, что это вряд ли измеримо.

Answer 4

Вопрос, на который вы действительно должны ответить, - это терпимость к потере данных.Количество запросов в секунду при передаче менее 1 Кбайт данных невелико, особенно при использовании json и xml.С другой стороны, на мобильных устройствах нужно учитывать время автономной работы, поэтому выполнение запроса каждые 5–60 секунд также возможно.

Нет причин, по которым вы не можете пакетировать свои обновления на сервер.

Если у вас нет допуска к потере данных, вы можете собрать свою партию из 50 обновлений в локальном хранилище и загрузить их.Если происходит сбой в передаче, вы можете отправить повторно.В этом случае, однако, я хотел бы иметь некоторый идентификатор записи, который разумно гарантированно будет уникальным, например, UUID.Таким образом, сервер может видеть, какие записи уже обработаны, и исключать их из повторной обработки.