Хранение научных данных в реляционной базе данных

Question

Я хочу хранить иерархические двумерные научные наборы данных в реляционной базе данных (MySQL или SQLite).Каждый набор данных содержит таблицу числовых данных с произвольным числом столбцов.Кроме того, каждый набор данных может иметь одного или нескольких дочерних элементов одного типа, связанных с данной строкой его таблицы.Каждый набор данных обычно имеет от 1 до 100 столбцов и от 1 до 1 000 000 строк.База данных должна иметь возможность обрабатывать множество наборов данных (> 1000), а чтение / запись данных должны быть достаточно быстрыми.

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

Answer 1

Целесообразно ли иметь "основную" таблицу с именами, идентификаторами и связями отдельных наборов данных, а также по одной таблице на набор данных, которая содержит числовые значения?

Вот как бы я это сделал.

Я не совсем уверен, как работает функция «произвольных столбцов», потому что данные обычно не работают так. В любом случае, это звучит как хранение, поскольку row, col, val могут работать хорошо.

Честно говоря, если вам не нужно искать по нему (макс, мин и т. Д.), Возможно, лучше использовать какой-нибудь плоский файл.

Альтернативная настройка, которая может быть интересна, - это использование SQLite с отдельным файлом базы данных для каждого набора данных, плюс один мастер-файл.

Что бы вы ни выбрали, насколько хорошо это будет работать, на самом деле зависит от того, что вы собираетесь делать с данными.

Answer 2

Я полагаю, что в конечном итоге вы потратите деньги на гибкость ради производительности.Вы можете жестко запрограммировать свою схему БД, которая, как кажется, вы хотите избежать, но даст вам лучшую производительность, или

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

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

Answer 3

Мы храним такие данные в их собственном плоском файле.Заголовок файла содержит достаточно информации (отметка времени, количество строк / столбцов и т. Д.), Чтобы его можно было прочитать.Затем метаинформация об этих данных находится в базе данных.Как минимум, это местоположение файла, но оно может содержать другую информацию о данных.Например, мы объединяем данные в прокси-переменные, которые суммируют детали на высоком уровне.Как правило, эти сводные данные достаточно хороши, но при необходимости мы можем прочитать файл для всех деталей.

Answer 4

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

Я бы посоветовал начать с того, что каждый набор данных должен быть в отдельной таблице (или таблицах, если есть дочерние записи), и создать основную таблицу, если вам нужно.

Я бы поделился вопросом zebediah49: «Вы действительно собираетесь использовать для этого базу данных? Разве плоские файлы не будут лучше?»