Дизайн базы данных для управления данными из последовательного порта?

Question

Я пишу коды для захвата данных последовательного порта (например, микрометра) и выполняю следующие действия:

1. отображение и отображение в реальном времени
2. удаление / изменение / замена существующих данных фокусоми повторное измерение
3. сохранение данных где-нибудь для дополнительного статистического анализа (например, в Excel).Таким образом, в качестве .csv это также опция

Поскольку каждое измерение может собирать от сотен до тысяч данных (точек измерения), я не уверен, как мне будет спроектировать мою базу данных - я долженсоздать новую строку для каждых полученных данных, или я должен поместить все данные в массив и сохранить их как сверхдлинную строку, разделенную запятой в базе данных?Для такого приложения мне нужен Server 2008 или будет достаточно Server 2008 Express?Каковы их плюсы / минусы с точки зрения производительности?

Можно ли создать такое приложение, где клиенту не нужно будет устанавливать sql сервер?

Answer 1

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

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

Answer 2

Что вы хотите (или, как вы думаете, вы хотите) для реляционной базы данных?

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

1. Вам нужно поделиться данными с другими, кто использует данные, где, по сети?(это будет определять формат, в котором вы сохраняете данные, и некоторые другие вещи)
2. Сколько данных вам нужно хранить, как быстро они измеряются и в течение какого периода времени измерять и хранить эти данные?(это скажет вам, использовать ли сжатие или какую-то другую схему экономии пространства или нет, это также даст вам указание на требования к ресурсам)
3. Насколько легко его можно извлечь?(это даст указания относительно того, какое управление данными вам необходимо: как называть файлы, где их хранить ...)
4. Какой анализ вам необходим для этого?(Вы хотите проанализировать несколько файлов вместе, только один файл, данные за определенный день, данные для данного порта ...?)

... и еще много таких вопросов.

В зависимости от ответов на эти вопросы вы можете быть довольны старым компьютером 386 или вам может потребоваться современный 8-ядерный.

Answer 3

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

Чтобы ответить на ваш основной вопрос, я бы рекомендовал использовать базу данных, только если это действительно имеет смысл. Будете ли вы выполнять запросы к данным или просто хотите хранить и извлекать записи по какому-то идентификатору? Я бы не рекомендовал хранить ее как супер длинную строку, разделенную запятыми, но вместо этого изучил тип BLOB. С помощью больших двоичных объектов вы можете помещать типы данных в базу данных, чтобы вы могли легко вернуть их обратно, плюс я считаю, что это намного эффективнее. Я бы предложил использовать тип TEXT, только если вам нужно выполнить какой-то текстовый запрос. Например, полнотекстовый поиск