Ждал подобного предложения Никаких аргументов "почему нет" привести не могу по той причине что никогда СУБД не занимался. Ну разве что

Мальчишество конечно, но все же 

Вполне возможно. Но столь же вероятна СУБД в роли "коровы на бане", и не исключено что в конце-концов не устроит скорость или что еще. Кстати, я впервые слышу что, оказывается, есть СУБД (sqlite) которые работают медленно.

Ну хорошо, попробуем более конкретно. Есть 1 миллион анимационных кривых, нужно прочитать все их значения для заданного кадра. Какое время займет это при использовании СУБД (какой - Вам виднее) ?

Или совет дан чисто их общих соображений: данных много - значит СУБД (подозреваю что так  )

Хорошо, вот анимация "по кадрам"

C++ (Qt)
template<class T> Data;
struct CustomFrame {
 int m_frame;
 Data m_data;
};
std::vector<CustomFrame> theCurve;

Аргумент T или double или тройка double (координата), др варианты здесь не интересуют. Эл-ты хранятся в векторе по возрастанию m_frame. Чтение, запись, вставка и удаление реализованы с помощью lower_bound. Вектор может содержать любое кол-во эл-тов, напр для минуты анимации 1800 (30 fps). Разные вектора необязательно имеют одинаковые кадры (m_frame), хотя часто бывает и так.

И вот наша проблема в том что таких векторов (curves, кривых) становится слишком много, и мы хотим задействовать БД для их хранения. Тогда у меня такие вопросы

1) Что в БД будет "полями" и что "записями"? Если я верно понял из написанного выше, то 1 кривая = 1 запись. Тогда что с полями? Одно поле = все данные одного вектора? И для чтения всех кривых по заданному кадру нужно "прогрузить" их все, каждую целиком? Это очевидно не вариант. Выходит поля должны быть кадрами, и надо сразу их все создать. Ну не знаю, их может быть много тысяч. И что если напр всего кадров 4K, а конкретная кривая имеет только 100? Все равно хранить все 4K?

2) Этот и след вопрос скорее из люботытства. В моем (наивном) представлении БД = нечто "стабильное". Типа "пришел утром и залогинился к своей базе". Но здесь др ситуевина: юзер открывает окно, указывает число размножаемых копий и диапазон времени - все, погнали, извольте создать базу с большим кол-вом полей. Так можна?  

3) Какую конкретно СУБД Вы бы порекомендовали (можно "настоятельно" ), и что Вы вообще думаете о привлечении СУБД в данном случае? Напр

а) безусловно необходимо
b) возможно
с) та ну нафиг

?

Спасибо

Хотя... я тут подумал, не сильно то и нужна СУБД в данном случае. Можно бинарку, все эти 100500 curves для одного фрейма можно сложить просто в бинарный файл с названием, содержащим идентифиактор этого фрейма.
Вот с изменениями в середине фала, будет небольшой, но в принципе решаемый гимор.

Вооот, а в БД это делается одной строчкой )))
Ну ладно, 3 командами, insert/update/delete
Ну и выборка по фрейму автоматом получится.
В общем набросать прототип, который внутри инкапсулирует работу БД, дело на 2-4 часа. Не понравится, пусть этот прототип инкапсулирует работу с файлами.

Чуть ранее я писал про индексацию таблицы по нужным параметрам (в данном случае по фрейму), т.е. будет одно или несколько полей для выборки данных по ситуации. По фрейму, или допустим понадобится упорядочить curves по какому-либо признаку, можно добавить еще поле а-ля "вес", добавить поле с информацией о типе (1 дабл или 3 дабла в в структуре хранятся) и т.д.
Не надо полностью ничего загружать, надо написать запрос типа
подставляем в параметры ("?") идентификатор фрейма, получаем данные только для конкретного фрейма.

Вообще странный вопрос... СУБД могут петабайтами информации ворочать и не загибаются.
Файловая sqlite у меня работала с БД до 5Гб (на бОльший объем не проверял, но уверен, справится), делала join выборку с результатом в 40 лямов строк (кривой запрос + кривые данные были).
Постгрес в прошлом моем проекте работал с таблицами по 20-30 лямов строк, объем БД был 50Гб.
Текущий проект в БД пишет по 1Тб в сутки, выборки правда довольно редкие.

Хорошо, подытожу вопросы
1. Структура базы
Это тупенькая структуркв записи верная, или можно как-то получше? Собсно мне нужно читать/писать значения для кадра кривой (читать макс быстро) - и все

2. Какую конкретно СУБД брать имея ввиду что мне нужно "доставить БД из кармана" (т.е. создавать ее втихаря когда юзер нажал кнопку), и сохранить (сериализовать) ее в своем файле данных. Т.е. чтобы не требовались какие-то внешние драйвера, установка в рамках ОС и.т.п.

Спасибо